■i,  h- 


AFIT/GeS/ENG/9lD-09 


A243  743 


AN  OBJECT-ORIENTED  DATABASE 
IMPLEMENTATION  OF  THE 
MAGIC  VLSI  LAYOUT 
DESIGN  SYSTEM 

THESIS 

Timothy  Martin  Jacobs 
Captain,  USAF 

AFIT/GGS/ENG/91D-09 


9 I- 19073 

II  iiiii  Nil;  mil  ii.,r..r:.y  •  w 


Approved  for  public  release;  distribution  unlimited 


91  1224  059 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No.  07C4-0788 


PuOu'cfCDortfr.g  curacn  'Cf  ;nin.ciicction  otintcffrauonis-wtimated  to  average  i  hour  cerreipoftsc.  Including  the  time  tor  reviewing  instructions,  searching  e;»isting  data  sources, 
gathering  ana  maintaining  tnedata  needed,  and  v^moietingandreviewing  the  vCMectionof  information.  Send  comments  regarding  this  burden  estimate  or  sny  ather  asoea  of  this 
collection  of  mioimaiion.  ncioding  suggestions  ‘or  reducing  thisOurcen.  to  Washingtors  rieddouarters  Se^ices.  Oirer.orate  lor  information  Ooerattcnsand  Reports.  12.5  ^efferson 
OavisHighway.  Suite  UC^.-Mfiington,  /A  22202-A302.andto  the  Officeof  Management  and  9udget.P3P€rwor>tReduaionPro]ecl(0704.0188>,//asnt'ngton.  OC  20503. 


AGENCY  USE  ONLY  (Leave  blaryk) 


2.  REPORT  DATE 
;  December  1991 


4.  TITLE  AND  SUBTITLE 

AN  OBJECT-ORIENTED  DATABASE  IMPLEMENTATION 
OF  THE  MAGIC  VLSI  LAYOUT  DESIGN  SYSTEM 


6.  AUTHOR(S) 

Timothy  M.  Jacobs,  Capt,  USAF 


;  7.  PERFORMING  ORGANIZATION  MAME{S)  AND  AODR£SS(£S) 
i  Air  Force  Institute  of  Technology,  WPAFB  OH  45433-6583 


5.  REPORT  TYPE  AND  DATES  COVERED 
Master’s  Thesis 


5.  FUNDING  NUMBERS 


3.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

AFIT/GCS/ENG/91D-09; 


i9.  SPONSORING/ MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

i  RL/OCTS 
1  Rome  Labs 
j  Griffis  AFB,  NY  13441 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 


1 12a.  DISTRIBUTION /AVAILABILITY  STATEMENT 
j  Approved  for  public  release;  distribution  unlimited 


13.  ABSTRACT  (Maximum  200  words) 

^  This  thesis  attempts  to  prove  that  the  commercially  avadlable  ObjectSiore  data  management  system  provides  the 
performance  and  functionality  necessary  to  support  a  complex  engineering  draign  system.  This  is  accomplished 
by  modifying  the  Magic  VLSTcircuit  layout  design  system  to  eliminate  its  current  Unix  file  data  management 
system  and  replace  it  with  ObjectStore,  The  approach  to  this  research  effort  includes  a  design  recovery  of  the 
Magic  system  and  identification  of  its  key  data  management  functions.  These  functions  are  then  modified  to 
take  advantage  of  the  database  management  facilities  of  ObjectStore.  Additional  code  is  Fidded  to  instrument 
performance  measurement  of  both  the  original  and  the  ObjectStore  versions.  of  the  Magic  system.  Testing  is 
accomplished  using  existing  Magic  commands  to  test  key  database  performance  criteria.  The  ObjectStore  version 
of  Magic  performed  better  than  the  original  version  for  some  performance  criteria  and  significantly  slower  than  the 
original  version  for  other  criteria.  The  conversion  effort  was  difficult  and  time  consuming  due  to  the  complexity  of 
the  original  Magic  software  and  the  ObjectStore  database  management  system.  A  more  specific  implementation 
of  ObjectStore  capabilities  is  necessary  for  conclusive  results.  . 


14.  SUBJECT-TERMS 

Objecti^'Oriented,  Database  Management  System,  Computer^ided  Design, 
jf^Very  Large  Scale  Integration  ^ 

15.  NUMBER  OF  PAGES 

72 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION 

18.  SECURITY  CLASSIFICATION 

19.  SECURITY  CLASSIFICATION 

20.  LIMITATION  OF  ABSTRACT 

OF  REPORT 

OF  THIS  PAGE 

OF  ABSTRACT 

unclassified 

UNCLASSIFIED 

UNCLASSIFIED 

UL  _ 

NSN  7540-01-280-S500 


Standard  Form  298  (Rev,  2-89) 
Prcicribfd  by  ANSI  Std.  239-18 
298-I02 


AEIT/GCS/ENG/91D-0? 


AN  OBJECT-ORIENTED  DATABASE  IMPLEMENTATION 
OF  THE  MAGIC  VLSI  LAYOUT  DESIGN  SYSTEM 


THESIS 


Presented  to  the  Faculty  of  the  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  University 
In  Partial  Fulfillment  of  the 


Requirements  for  the  Degree  of 
Master  of  Science  (Computer  Systems) 


Timothy  Martin  Jacobs,  B.S.,  M;S,B.A. 
Captain,  USAF 

December  1991 


Approved  for  public  rele2ise;:  distribution  unlimited 


Table  of  Contents 


Page 

Table  of  Contents  . . . .  •  •  .  i] 

List  of  Pigures . . .  .  .  v 

List  of  Tables  . . . . . . .  Vi 

Abstract  . . . . .  vii 

I.  Introduction  . . . . .  1 

1.1  Overview . . . .  .  .  .  1 

1.2  Background  . .  2 

1.3  Problem  Statement .  3 

1.4  Research  Objectives  . .  3 

1.5  Assumptions  .  .  .  .  . . 5 

1.6  Scope  and  Limitations . . . -  5 

1.7  Methodology . 6 

1.8  Materials  and  Equipment  . .  8 

1.9  Document  Summary . 8 

II.  Databases  and  Design  Systems:  Relevant  Issues  .  9 

2.1  Overview . 9 

2.2  Engineering  Design  and  Database  Mahageirient  Systems  .  ;  .  .  .  9 

2.3  Database  Performance  .....  . . 10 

2.3.1  PerformanceEvaluation . ll 

2.3.2  Design  Issues  Impacting  Performance .  12 

2.4  The  Objects  tore  Database  Management  System .  12 

2.5  The  Magic  VLSI  Layout  Design  System  .  . .  14 

2.6  Summary . 15 

ii 


Page 


III.  Design  and  Implementation  of  Magic  Using  ObjectStore  . . . 

3.1  Overview . . . .  .  . 

3.2  Magic  Design  Recovery  . . .  i  .....  . 

3.3  Restructuring  of  Magic  Software  to  Work  with  ObjectStore  .  .  . 

3.4  Code  Instrumentation  for  Performance  Measurement  . . 

3.5  Testing  . . . 

3.5.1  Testing  Magic  Functionality.  . . 

3.5.2  Performance  Testing. .  . . 

3.6  Summary . 


TV.  Results  Analysis  . . . ;  .  .  . 

4.1  Overview . . . . . 

4.2  Performance  Comparison  of  ObjectStore  and  Flat  Data  Files  .  . 

4.3  Conversion  to  ObjectStore..  .  . . 

4.3;1  Problems  Encountered . 

4.3.2  Effort  Required.  *  .  . . . . . 

4.4  Summary . . . 


V.  Conclusions  and  Recommendations  . 

5.1  Overview  . . 

5.2  Summary  of  Research . 

5.3  Conclusions . 

5.3.1  Database  Functionality.  .  .  ;  . 
5.3;2  Database  Performance.  .  .  .  . 

5.3.3  Conversion  Cost  Effectiveness. 

5.4  Recommendations  for  Further  Research 

5.5  Summary . 


Appendix  A.  Raw  Performance  Test  Results 


17 


17 

23 

28 

28 

28 

29 

31 

32 
32 
32 
40 
40 

43 

44 

45 
45 
45 

45 

46 
46 

48 

49 

51 

52 


in 


Page 

Bibliography . . . .  .  .  ^ . . . •  .  •  •  62 

Vita . . . .  64 


iv 


List  of  Figures 


Figure  Page 

1.  Corner  stitching  oFtiles  in  a  plane  . .  15 

2.  High-levd  Magic  directory  organization . . . .  .  19 

3.  Data  structure  for  Magic  cells  . 20 

4.  Relationship  between  cell  definitions  and  cell  uses . 22 

5.  Code  modifications  to  function  magzcMain . 25 

6.  Sample  header  file  modifications  from  tile.h . 26 

7.  Magic  display  of  cell  drfmchip .  33 

8.  Magic  display  of  cell  tut4a . 34 


V 


List  of  Tables 

Table  Page 

r.  DBMS  Support  of  Engineering  Design  Tool  Characteristics  .........  4 

2.  Benchmark  performance  results  for  drfm  database . 36 

3.  Benchmark  performance  results  for  tutorial  database . 37 

4.  ObjectStore  performance  at  two  different  levels  of  subcell  nesting .  38 

5.  ObjectStore  performance  comparison  with  two  different  cache  sizes .  39 

6.  Comparison  of  ObjectStore  and  Unix  flat  file  disk  usage . .  .  40 

7.  Man  days  spent  converting  Magic  to  work  with  ObjectStore  .  44 


vi 


AFIT/GCS/ENG/91D-09 


Abstract 

Despite  the  many  advantages  provided  by  database  management  systems,  many  com¬ 
plex  applications  spurn  their  use  in  favor  of  application  unique  file  management  systems. 
This  is  primarily  due  to  the  inadequate  performance  of  conventional  database  systems. 
Recent  research,  however,  has  indicated  the  potential  for  object-oriented  data,base  systems 
to  fulfiU-the  performance  requirements  which  these  complex  applications  demand. 

Among  these  complex  applications  are  engineering  design  systems.  This  thesis  at¬ 
tempts  to  prove  that  the  commercially  available  ObjectStore  data  management  system 
provides  the  performance  and  functionality  necessary  to  support  a  complex  engineering 
design  system.  The  Magic  circuit  layout  design  system  is  modified  to  eliminate  its  current 
Unix  file  data  management  system  and  replace  it  with  ObjectStore. 

The  approach  to  this  research  effort;  includes  a  design  recovery  of  the  Magic  system 
and  identification  of  its  key  datamanagement  functions.  These  functions  are  then  modified 
to  take  advantage  of  the. database  management-facilities  of  ObjectStore.  Additional  code 
is  addedlto  instrument  performance  measurement  of  both  the  original  and  the  ObjectStore 
versions  of  the  Magic  system.  Testing  is  accomplished  using  existing  Magic  commands  to 
test  key  database  performance  criteria. 

The  ObjectStore  version  of  Magic  performed  better  than  the  original  version  for  sonae 
performance  criteria  and  significantly  slower  than  the  original  version  for  other  criteria. 
The  conversion  effort  was  difficult  and  time  consuming  due  to  the  complexity  of  the  orig¬ 
inal  Magic  software  and  the  ObjectStore  database  management  system.  A  more  specific 
implementation  of  ObjectStore  facilities  is  necessary  for  conclusive  results. 


vii 


AN  OBJEGT-ORIENTED  DATABASE  IMPLEMENTATION 
OF  THE  MAGIC  VLSI  LAYOUT  DESIGN  SYSTEM 


L  Introduction 


1.1  Overview 

Database  management  systems  (DBMS)  have  proven  themselves  in  a  large  variety  of 
computer  applications.  Today’s  commercial  DBMSs  provide  an  effective  tool  for  managing 
large  repositories  of  data  while  providing  access  to:'multiple  users  and  applications.  All 
users  have  access  to  the  same  data  since  it  is  stored  in  a  single  location.  Concurrency 
control  and  recovery  methods  ensure  data  consistency  despite  multiple  users  and  hardware 
or  software  failures.  Applications  can  be  easily,  added  without  knowledge  of  the  physical 
layout  of  the  data,  Overall,  modern  DBMSs  provide  numerous  advantages  over  alternate 
data  management  facilities. 

Despite  these  many  advantages^  there  are  numerous  computer  applications  which 
continue  to  spurn  the  use  of  a  DBMS  un  favor  of  their  own  unique  application  file  system. 
Among  these  are  engineering  design  systems  which  are  heavily  dependent  on  large.amounts 
of  computer  data.  Few  applications  systems  which  support  these  design  processes  are 
integrated  with  a  DBMS. 

Although  conventional  databases  are  unable  to  adequately  support  these  applica¬ 
tions,  the  need  for  some  sort  of  database  support  becomes  evident  as  the  systems  proliferate 
among  more  powerful  workstations  and  in  increasingly  complex  engineering  environments. 
Object-oriented  database  management  systems  (OODBMS),  while  still  not  widely  avail¬ 
able,  have  shown  the  potential  for  providing  the  necessary  database  support  for  these 
complex,  data  intensive  applications. 

This  thesis  examines  the  potential  of  object-oriented  databases  to  support  complex 
design  applications.  A  very  large  scale  integrated  (VLSI)  circuit  design  tool  is  implemented 
on  a  newly  released  commercially  available  OODBMS.  The  performance  of  this  tool  as 
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implemented  on  the  OODBMS  ds  compared  to  its  performance  as  currently  implemented 
with  ailat  file  system.  Conclusions  are  drawn  about  whether  an  OODBMS  can  adequately 
support  a  complex,  data  intensive,  automated  design  system. 

1.2  Background 

Computer-aided  engineering  design  tools  have  been  developed  for  a  number  of  ap¬ 
plications  such  as  integrated  circuit  design,  software  engineering,  and  machinery  design. 
Typically,  such  tools  assist  the  designer  by  providing  graphical  repr^entations  of  the  de¬ 
sired  object  along  with  a  narrative  or  symbolic  description.  A  repository  of  previously 
defined  objects  exists  from  which  the  designer  may  choose  airobject  to  incorporate  into 
the  new  design.  A  designer  can  start.with-a  high  level  view  of  the  desired  object  and  grad¬ 
ually  refine  the  design  down  to  the  tiniest  detml.  This  process  ma}'  occur  over  a  period 
ranging  from  hours  to  months. 

The  data  associated  with.a  typical  design  contains  many  complicated  relationships 
among  various  data  items.  A  complete  design  object,  such  as  a  VLSI  circuit  or  an  au¬ 
tomobile,  may  have  thousands  of  individual  data  components.  Additionally,  computer 
representation  of  graphicaband  textual  data  requires  vast  amounts  of  storage  and  is  often 
unique  to  a  specific  hardware  or  software  system. 

The  relational  database  management  systems  which  are  currently  widely  available 
were  originally  designed  to  support  business  applications.  As  such,  these  DBMSs  are 
oriented  toward  individual  data  records  and  simple  data  objects  such  as  bank  accounts. 
The  relationships  among  various  objects  are  limited  and  rather  well  defined.  Datatypes 
are  typically  numbers  or  short  textual  descriptions.  Individual  transactions  usually  involve 
only  a  few  operations  on  a  small  number  of  records  and  relations.  Such  transactions  are 
completed  in  fractions  of  a  second. 

The  difference  between  the  data  requirements  of  engineering  design  tools  and  those 
of  business  applications  for  which  currently  available  database  systems  were  developed  is 
significant.  Attempts  at  implementing  design  tools  on  these  conventional  DBMSs  have 
produced  results  ranging  from  excessive  processing  time  to  outright  failure.  To  overcome 
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these  problems,  considerable  research  has  been  undertaken  to  develop  a  DBMS  suitable  for 
the  data  representations  and  time  constrmnts  of  complex  applications  such  as  engineering 
design  tools.  Considerable  promise  in  this  area  has  been  shown  using  object-oriented 
database  management  systems. 

The  tiieory  behind  object-orient^  database  management  systems  is  to  incorporate 
the  object-oriented  programming  paradigm  into  a  database  system  which  provides  concur¬ 
rency  control,  failure  recovery,  relationship  modeling,  and  data  persistency.  Key  elements 
of  the  object-oriented  paradigm,  which  simplify  representation  of  compie.x  applications, 
include  object  identity,  data  encapsulation,  complex  state,  and  inheritance.  Many  experi¬ 
mental  OODBMSs,  and  the  few  commercially  availablc.OODBMSs.  also  support  complex 
data  types,  multiple  versions,  and  long  transactions. 

Table  1  presents  the  characteristics  of  an  engineering  design  tool  along  with  a  com¬ 
parison  of  support  providtkl  by  currently  available  relational  DBMSs  and  object-oriented 
DBMSs.  From  this  table  it  is  evident  that- stgoed  OODBMS  can  potentially  provide  the 
database- support  necessary  for  a  complex  application  such  as  an  engineering  d«ign  tool. 

I. 3  Problem  Stalement 

Traditional  database  management  systems  (typically  relational  models)  perforin  too 
slowly  for  complex,  data  intensive  applications  such  as  computer-aided  engineering  design. 
As  a  consequence  of  this  slow  performance,  most  design  tools  have  their  own  file  system. 
Such  file  systems  require  data  management  to  be  accomplished  manually,  often  by  various 
individuals  in  the  design  organization.  Manual  data  management, -in  turn,  increases  the 
potential  for  errors  siich  as  deleting  or  modifying  the  wrong  version  of  a  design.  In  addition, 
a  change  to  thc  structurcof  any  of  the  files  raiuircs  Ganges  to  all  programs  which  reference 
the  modified  structure.  This  increases  the  inaintcnancc  effort  required  for  the  systeni. 

J. .j  Research  Objeclives 

The  primary  purpose  of  this  thesis  is  to  determine  whether  or  not  an  object-oriented 
database  management  system  provides  the  performance  and  functionality  necessary  to 
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Object-Oriented 

DBMS 


Complex  State 


Multiple  Views 


Phased 

Development 


Fast 

Performance 


Graphical  represen¬ 
tation  of-a  circuit. 


Top  level  view' of 
design  or,  more 
detailed  look  at  a 
sub-component. 


Current  and 
historical  versions. 


Thousi 


Designer  takes-two 
weeks  to  modify  a 
specific  circuit 
de-sign. 


A  key  is  required  for 
each  sub-component. 
Joins  are  required  to 
merge  into  a  single 
object. 


Complete  specification 
of  the  schema  must  be 
defined  a  priori. 


0‘a.  supports^basic 
data  types  such  as 
integer  and  character. 


Must  beidefined  in  the 
application.  Limited  by 
record  oriented  retrieval. 


May  support  multiple 
versions  of  individual- 
records. 


Limited  only  by  physical 
sloragepiiowever, 
record-onentedrstorage 
may  limit  the  size  of 
record,  causing  multiple 
record  retrieves  for  a 
single  object. 


Built  arqund-short  ' 
business  transactions. 
Inefficiency  and  failure 
occur  with  long 
transactions. 


A  single  view  requires 
multiple  joins  :ahd  many 
individu^  accesses. 


Fundamental  to  the 

object-oriented 

paradigm. 


Fundamental  to  the 

object-oriented 

paradigm. 


Supportsfgraphical  and 
.  textual  data  and  allows 
user  to  define  data 
types. 


Can  be  specified  as  a 
method  for  the  object. 
Data  is  inore  easily 
retrieved  using 
object-oriented-storage 
tecluiiques. 


Generally“built-in  as  a 
tree  structure  with  root 
node  representing  a 
version.  Tree  includes 
all  objects  which  make 
up  the  version. 


Refined'schemai  can 
inherit  characteristics  of 
a  higher  level  and 
■modify  for. next  phase. 


Clustering  by  object 
reduces  the  nuinber  of 
disk  accesses.  Complex 
data. types  remoVe 
object  size  restrictions. 


More  apjprbpriate 
concurrency  control  and 
failure  recovery^methods 
uscd  to  support  long 
transactions. 


Table  1.  DBMS  Support  of  Engineering  Design  Tool  Characteristics 
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support  a  typical  computer-aided  design-tool.  To  fulfill  this  objective,  the  design  tool  must 
maintain  all  functionality  provided  by  the  existing  file  management  system.  Performance 
of  the  design- tool  must  remain  acceptable  tg4he  tool  users.  This  is  specified^  as  no  more 
than  a  ten  per  cent  increase  in  response  time  over  the  current  implementation. 

This  thesis  should;  also  demonstrate  that  conversion  of  a  design  too!  application  from 
a  unique  flat  file  management  system  to  an  OODBMS  is  not  a  difficult  or  time  intensive 
task.  To  meet  this  goal,  the  time  and  effort  spent  converting  to  the  OODBMS  must  be 
cost  effective  with  respect  to  the  increased  utility  of  a  (’  •  abcise  management  system  and 
the  reduction  in  future  software  maintenance-costs. 

1.5  Assumptions 

If  the  results  of  this  thesis  are  to  be  applied  to  other  engineering  design  tools,  the  tool 
impleinented  (i.e.  the  Magfic  VLSI  circuit  design  tool)  must  be  typical  cf  all' engineering 
design  tools. 

Due  to  the  inexactness  of  the  available  techniques  for  measurihg  results,  assumptions 
are  made  about  disk  access  times  and  actual  processing  times.  These  assumptions  are 
described  and  justified  along  with:the  results^obtained. 

A  similar  lack  of  preciseness  and  a  large  amount  of  subjectivity  occur  when  calculating 
the  added  value  of  a  DBMS  and  when  estimating  future  maintenance  costs.  Assumptions 
regarding  these  values  will  also  be  described  and  justified  along  with  the  results. 

1.6  Scope  and  Limitations 

This  thesis  implements;  a  direct  conversion  ofcodeTor  the  Magic  VLSI  cijcuit  design 
tool  from  the  existing  file  system  to  the <06yecf5<ore  object-oriented  database  liianagement 
system.  This  includes  conversion  of  C  code- for  compatibility  with- the  ObjectStore  C-/--/- 
compiler.  Software  redesign  is  accomplished  only  m  necessary  to  make  Magic  work  with 
QbjectStore, 
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No  attempt  is  made  to  improve ;thctporformancc  of  Magicby  -modifying  the  existing 
software  structure.  All  algorithms  and  data  structures  remain  unchanged.  Data  structures 
are  added  only  to  replace  current  code  which  directly  accesses  physical  datafiles^ 

f.7  Methodology 

Magic  is  a  VLSI  circuit  layout  design  tool  which  is  commonly  used  at  the  Air  Force 
Institute  of  Technology  (AFIT)  and' other  U.S.  institutions.  A  number  of  people-at  AFIT 
are  familiar  with  the  functionality  and  performance  of  thisftool.  It  containsThe  character¬ 
istics  of  a  typical  computer-mded  engineering  design  system  as  described  In  Section  1.2. 
Magic  manages  data  with  its  own  unique  flat  file  system.  Because  ofits  familiarity  among 
AFIT  personnel,  its  typical  deMgn  tool  characteristics,  andits  currentdat  file  management 
system,. Magic  is  selected^to  test  the  potential  of  an  object-oriented  database  manageinent 
system. 

Few  commercially  available  OODBMSs  currently  e^st.  Among-thesels  the  Object- 
Store  database  management  system  developed  by  Object  Design  Incorporated  of’Burling- 
toh,  Massachusetts.  This  OODBMS'has  been  inade  available  to.AFIT  andls  used  for  this 
thesis  to  implement  the  Magic  VLSI  circuit  design  tool. 

The  first  part  of  this  thesis  requires  implementation  of  Magic  with  the  ObjectStore 
DBMS.  Thislmplementation  follows  the  steps  described  below. 

1.  Accomplish  a  design  recovery  on  the  Magic  system.  This  provides  am  understanding 
of  the  software  structure  and  functionality  and  is  necessary  since  a  limited  amount 
of  design  documentation  currently  exists^ 

2.  Replace  existing  file  input  and  output  with  persistent  database  structures.  This 
involves  eliininating  all  file  input  and  output  and  making,  program  data  structures 
persistent.  ILno  data  structure  exists  because  dataisidirectly  extracted  or  replacedin 
a  file,  then  a  persistent  data  structure  is  created  which  is  similar  to  the  file  structure. 

3.  If  necessary,  redesign  software  which  can  not  be  implemented  with  ObjectStore. 
Redesign  is  accomplished  in  a  manner  similar  to  existing  Magic  code  with  emphasis 
oil  generally  accepted  object-oriented  design  procedures. 
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Performance  comparison  of  the  existing  implementation  of  Magic  to;its  implementa¬ 
tion  using  Ob jectStore  requires  computation  of  performance  characteristics.  These  calcu¬ 
lations  involve  the  tasks  described  here. 

1.  Instrument  code  in  critical  regions  of  the  software  to  measure  . processing  time.  This 
code  must  occur  in  the  same  place  for  both  the  existing  implementation  of  Magic  and 
the  ObjectStore  implementation.  In  general,  those  sections  of  software  most  likely 
affected  by  the  database  management  system  are  instrumented  for  ;processing  time 
measurement. 

2.  Instrument  code  in  the  existing  software  to  measure  disk  accesses.  Accomplish- this 
for  those  segments  of  code  involving  file  input  and  output. 

3.  Extract  disk  access  information  from  the  ObjectStore  DBMS.  This.extracted  infor¬ 
mation  involves  the  same  data  as  the  file  access  data  in  item  2  above. 

The  second  objective  ofthis  thesis  is  to  show  that  the  conversion  effort  is  cost  effective 
with  respect  to  reduced  futurermaintenance  and  increased  utility  of  aDBMS,  Measurements 
for  these  comparisons  are  reached  with  the  following  steps. 

1.  Identify  time  spent  converting  the-existing  Magic  system: to  an  OODBMS. 

2.  Subjectively  evaluate  the  difficulty  of  the  conversion  based  on  the  learning  curve  for 
ObjectStore  and  the  actual  code  modifications  which  were  accomplished. 

3.  Subjectively  estimate  the  benefits  of  having  Magic  implemented:with  a  DBMS.  This  is 
accomplished  by  interviewing  users-of  Magic  a.nd  by  researching  other  organizations’ 
uses  ofrdesign  tools.  The  results  of  the  interviews  and  research  are  interpreted  m  to 
their  compatibility  or  incompatibility  with  i  DBMS. 

4.  Subjectively  estimate  the  reduction  of  future  maintenance  costs  based  on  existing 
studies  of  the  cost  of  maintenance  and  -consultatidns  with  software  personnel;  who 
have  experience  in  software  maintenance. 


1.8  Materials  and  Equipment 

This  research  effort  utilizes  the  ObjectStore  (version  1.1)  database  and  development 
facilities:on  a;5unr5parc  //  workstation.  ObjectStore  provides;all  tools  necessary  to  convert 
the  Magic  system.  The  Magic  software  is  also  available  on  &  Sun  Sparc  II  workstation  for 
modification  and  testing. 

1.9  Document  Summary 

Chapter  2  describes  previous  research  on  object-oriented  databases  in  support  of 
computer-aided  design  appUcatipns.  This  chapter  also  describes  the  functional  aspects  of 
the  Magic  VLSI  layout  system  and  the  ObjectStore  DBMS.  Chapter  3  presents  a  design 
recovery  of  Magic  and  discusses  the  methodology  employed  in  implementing  Magic  with 
the'ObjectStpre  database.  A  cpmparison  of  Magic  performance  =and  the  effort  involved 
in  conversion  to  ObjectStore  is -contained  in  Chapter  4.  Chapter  5  includes  conclusions 
reached  fegarding'the  objectives  of  this  thesis -and  recommendations  for  further-research. 
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JR  Databases  and  Design  Systems:  Relevant  Issues 

2.1  Overview 

T=he  field  of  object-oriented  databases  is  relatively  newand  few  implementations  have 
actually  been  put  into  practical  use.  This  chapter  reviews  existing  research  on  object- 
oriented;  databases  with  engineering  design  systems  and  discusses  the  ipotential  benefits. 
Additional  database  design  issues  are  discussed  along  with  their  impact  on  performance.  A 
brief  overview'is  presented  of  the  Magic  layout  design  system;  and  the  ObjectStore  database 
management-system. 

2:2  Engineering  Design  and  Database  Management  Systems 

Developers  ofautomatedidesign  systems  have  long  been  searehing  for  database  man¬ 
agement  systems  which  meet  the  performance  -requirements  necessary  for  manipulating 
complex  engineering  entities.  Thomas  Sidle  identified  Weaknesses  of:  Commercial  Data 
Base  Management  Systems  in  Engineering  Applications  (:17)  as-  early  as  1980.  These 
weaknesses  include  slow  response,  excessive  discipline  imposed  on  the  software  #velop- 
ment  activity^  difficulty  of  satisfying  engineering  requirements,  and  organizationa!  prob¬ 
lems  associated  with  databasessuppgrt.  The  primary>reason  for  these  inadequacies  is  the 
orientation  ofexisting  DBMSs^owafd  business  applica.tions, 

A  typical  business  database  consists  of  a  large  niimber  of  structurally  simple  records. 
Most  transactions  involve  sirnple  requests  to  locate  and  perform  siiiiple  operations  on 
a  small  number  of  records.  The  record  structures,  operations,  cpncurrency  control  tech¬ 
niques,  and  failure  recovery  methods  of  conventional  DBMSs  are  designed  to  support  these 
business  databases.  Inefficiencies  and  failure  result  when  these  DBMSs  are  used  to  support 
engineering  design  applications.  (T7) 

Instead  of  conventional  DBMSs,  inany  datable  experts  have  proposed  Object- 
Oriented  Databaise  Management  Systems  as  more  appropriate  for  engineering  design  sys¬ 
tems.  According  to  Sandra  Heiler  etq/  (4),  an  object-oriented  approach  to  data  manage¬ 
ment  supports  engineering  design  requirements  by  allowing  users  to  define  relationships 
among  engineering  objects  and  by  providing  facilities  for  defining  complex  objects  and 
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version  configurations.  Changes  tp  data  items  are  controlled  by  limiting  the- operations 
ithat^can  be  appliedito  ah  object  to  those  which  are  specifiedun  the  object  type  description. 
‘By  allowing  the  user  tOiSpecify  the  behavior  of  an  object, lOODBMSs  support  triggering 
of  changes  to-derived  objects.  Operations  can  also  be  specified  for  logging  changes  to 
an  object  and  for  defining  policies  for  relationships  between  objects.  The  object-oriented 
iparadigni  provides  a  better  modekfor  mapping  to  the  mental  model  of  the  users.  System 
maintenance  is  siinplified  since  “changes  to  the  implementation  of  one  object  or  object 
type  wiU:  not  require  changes  to  others  (4:339).”  Using  the  inheritance  characteristic  of 
object-oriented  DBMSs,  new  objects  can  be  added  or  old  objects  modified  as  requirements 
are  refined.  Different  implerhentations.of  an  operation  or  data  structure  can  be  defined 
without  affecting  the  interface  of  the  object  to  other  objects. 

Rajiv  Gupta  et  a/.-(3)  point  out  similar  advantages-of  ah  OODBMS.  'Bhe  pbject- 
orieilted  paradigm  mimics  real-world  objects,  encourages  gradual  evolution  of  a  design, 
and  encourages  code  reusability.  By  stpringepowe'ful'data^strnctures  persistehtly  pfi  dislc 
sthe  heed  for  local  memory-resident  structures  is  eliininated  and;  retrieval  can  be.  optimized 
by  caching  entire  objectsdn  memory.  Aggregatiomallows  represehtatipn  of  complex  objects 
Avhich  reference  a  number  o&constitueht  objects,  An  object  which:  is  a  specialization  pf 
another  object  can  ibe  modeled  such  that  it  inherits  the  characteristics  pflthe-Kighet  Jevel 
object.  A  group  ok  objects  can  bp  represented;  as  a  class  such  that  eacb-instance  of  the 
.classihas^the  same  attributesjand  operations.  Gupta  et  akalso  point  out  a  fewtdrawbackf. 
of  OODBMSs.  These  include  increased  use  of  disk  space,  slower  response  than  filemased 
CAD  systems,  and  difficulty  in  finding  errorsmdUen  inLap  .ibptracted.iraplementatioridayef 
■of  ah  object. 

2.3  Database  Performance 

If  database  management  systems.are  to  replace  the  unique: file  management  systems 
which  are^common  in  engineering,  design  applications^  the  perfprmahce  of  these  DBMSs 
must  be  comparable  to 'the  existing  syetems.  The  fpUowihg  sections  discuss  methods  of 
evaluating  database  performance  and  some  design  issues  which  may  affect  the  performance 
■of  object-oriented  database  systems. 
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2.3.1  Performance  Evaluation.  Much  of  the  iitefatufe  on  database  performance 
evMuation  addresses  the  results- of  standard  benchmarks  as  applied  to  va,rious  DBMSs. 
While  most  of  these  benchmarks;reilect  ty;,.  » pplications  for  relational  DBMSs,  It.G.G, 
Cattel  has  developed  an  approach  for  rV'  --s  • ,  i  iuj  the  performance  of  object-oriented  data¬ 
base  systems'(2).  Before  discussing  lu.?  ,-p”-.  „  cl ,  however,  Cattel  points  put  that  “The 
most  accurate  measure  of  performance  for-,  igineerihg  applica,tioh3  would  be  to  fun  an  ac¬ 
tual:  application,  representing  the  data  in  :j! '  .auner  best  suited  to  each  potential  DBMS: 
(2:36d).” 

Cattel  proposes  a  database  of  parts  on  a  circuit  board  with  connections  between: 
them.  He  summa,rizes  the  three  most  important  measure.'i- of  perforinance  in  a.n  object- 
oriented  jDBMS  as: 

Lookup  and*  Retrieval.  Look  up  and  retrieyeran;ob ject  given  its  identifier . 

Traversal.  Dindiall  objectsdn  the  hierarchy  of  a  selected  object. 

Insert,  insert  objects:and=  their- relationships  to,  other  objects. 

To^meet  the  performance  requirements  of  engineering  appfications,  Gattel  suggests 
that  a  DBMS  must  be  able  to  perform  lOQO  random  operations  :pef  second.  iHerhotedsthat 
none  of  the  OODiBMS  implementations  in  research  or  productioh  environments  met  his 
criteria  whemhis  paper=was-v/riften  in  1987. 

Befre  and  Anderson’s^iTj/perMbde/  benchmark:(l)  presents  a=  similar  approach  toper- 
forinance  measurement.  In  addition  to  the;operatibns  proposed  by-Gatfel,  the  HyperModef 
benchmark  includes: 

Sequential  Scanv  Visit  each  objeetdn  the  database  sequentially. 

Clqsure  OperatipnSi  Perform;operations  onfall  objects  reachable  by  a  certain  relation¬ 
ship  from  a  specified  object. 

Open-and-Glose.  Time  to  open  and  close  theMatabaise. 
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2.%2  Desipi  Issues  impacting  Performance.  One  of  til's  key’deTigh  issues  affecting 
OODBMS  performance's  whether  or  not  to-clustev  subpbjects  and  their  referencing  obr 
jects  in=  physical  storage.  Jhingransand  Stonebraker^ 6):  address  thisils  jueiundithe  effect  of 
caching.  They  ruma  senes  ofcexperiinents  using  a  relational  DBMS  and  alhierarchical-  data 
structure  in.  which  the  number  of?shared  superobjects.aiid  subobjects  iswaried.  Jhingrari 
and  Stonebraker  show  clustering  to  be  advantageous  only  when  sharing  of  subobjects  is 
relat.  -eiy  low.  When  retrieving  objectsdn  a  homogeneous  collection,  clustering  decreases 
performanceisincesthe  objects  are  stored?with;their  superobjects  an*’  rtremo  longer  cpntigm 
ous  on  idisk.  Caching,  on  the  other  hand,  is  generally  viable  excepv  when  a  large  number 
of  updates  is  made. 

Another  design  issue  affecting,  performance  is  the  usetof  indexing.  Kim  et  al  (T) 
evaluate  two;diffefenfr  indexing  techniques.  The  fiirst  of  these  isian  index  riiaintainedlon  an. 
attribute  offa."single  class.  Kinir  etfa/adentify  this  as  a  single-class  index,  k  class-hierarchy: 
mdea:  is>maihtained?onian-attribute  of  ali  classes  inta  classluefarchy  rooted  atJa  particulai. 
class.  Two  different  case_s  Were  studied>.with=sthe  same  set  offfange'-values  varied  for  each- 
case.  In  one‘case?all  offthe  fan£  key  yuluesiare  assumed  toibe  iniany~pne  off  the  classes 
in  the  Hierarchy.  The  secondlcaseiscattersdhe  range  values  evenly  In  two-classes.  In-  both 
cases  class-hicrafdhy  mdexmg'generally.  -resuits  In-  fewer  Index  pages  bejng  fetched  for  a 
given  querylf  there  aretat  least  two  classes  in. a.class  hierarchy. 

2.4  The  ObjectStore  Database  MgnagementiSystem 

Because  of  the  complexity  of  object-oriented  databases  and;;the  immatUrity-’of  the 
field,  few  commercially  available  object-oriented  databases  exist.  Of  those  that  do»exist^ 
many  are  merely  object-oriented  interfaces  to  a  relationaUdatabase.  Only  recently  haye  any 
dltabases  been  commefcially  released  with  memofy  management  technlquesssuitable  for 
object-oriented  database  ma.hagement.  One  sUch  database  management  system  is  Object- 
Store,-an  object-oriented  database  management  system releaisedln  lQOOi  Witliian:  upgrade 
releaseiin  1991,  by  Object  I)esign,^Incorporated. 

ObjectStore-suppprts  most  of  the.object-orientedid?vtabase  characteristics  bsled  in; 
Table  1.  The  database  design  languageds  C-/"/-  wliich  prpvides.support  for  complejestate. 
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inheritance, 4nd  user  definedidata  types:(«18).  Specific  views  fof  :an  objectxan  be=expfessed= 
ini  the'Cr/r-Z-rfunctionSrassociated  with  that  object.  GbjectStore  alsoiproyides  a-versipningv 
mechaiiism  to  support  long  transactions-rand  multiple  visions.  To  diandle  large  amounts 
ohdata,  ObjectStore  uses  a  inemory  mapping  and  page  swapping  mechanism  which  can  be 
custornized  by  theidatabase  designer- (13)  ObjectStore  does  not  support  schema*evolution, 
Any  change'to  a  schemh  makes  data  creaced  with  the  old  schema  unreadable  by  thetneW 
program.  (16) 

In  addition  to  its=uniquely  object-oriented  characteristics,  ObjectStore  also  has  tra¬ 
ditional';  database  management  facilities.  All  access  to  the  databasemust  occur  within  a 
transaction.  All  data  nianipulation  which  occurs  within  a  transaction  ismot  visible*out- 
side  of  the  transaction- until  the  traiirvactiomis  complete;  This  avoids  the  potentiabdata 
integrity  problems  which  cans^oc  mr  if  two  separate- appUcatiphs  modify  or  use  the^sarne 
piece  pfidatasimultanepusly.  ©atafintegrity  is  alsorensufed  thfbughirelatipns  and  inverse 
relations  v/hich  synchronize  related  objects  when  one  oC  them  is  .modified.  ObjectStore 
provides  tools  for  managing  cpllectipns  (groups  of  hpmGgeueous  data)  andisuppprts  query 
processing  over  these  cdllectiphs.  ;(i3) 

Objects  tore’s  Virtual  Memo^  Mappings  ArcHitecture{VMMJ^y^^  key  tosits  perfor¬ 
mance.  This-  architecture  aUpws  persistent  data  stored  in  ObjectStore  to  be  handled  in 
the  sajne  way  as  non-persistent  (transient),  data.  Barge  amountS:ofidata?ca,n  be  retrieved 
aiid  nxanipulated  with  minimal  overhead  through,  virtual  memory  management.  When 
referenced  data  is  hot  inimainmempry,  a'jpageffaultipccurs  wiuch  is  ihterceptedJby  Object- 
Store  so  that  it  can  retrieve  the  data  from  the  databaseiihtomemory.  The  overafiiefiect 
ofithe  memory  m  apping:  architecture  is  to  provide  the  developer  a  single  View  of  memory 
— ^  basically  expanding  the  prpgram  memory  to  thejsize  of  theidatabase.  (13) 

For  amapplicatiom  to  work  with  ObjectStpre'-vhree*auXjIiary  processes  are  required- 
—  the  ObjectStore  Seryery  t^  Directory  Manager^^and  ihe  Cache  Manager.  The  Server 
handles  all  storage  and.  retrieval  of  persistent  data.  The  Directory  Manager  manages 
ObjectStore  directories  much  aS  Dnixmanagesiits  difectofies.  The  Cache  Manager  controls 
swapping  oBdata  between  theicachemempry  associated  with  amapplicatioh  andithe  virtual 
database  memory.  !(13); 
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QbjcctStorejprovides  interfaces  to  bpth-©  andiC-/--/-.  It  also  its  own  Dpa  Defini¬ 
tion  and  Maiiipulation- Language  (^DML)!iwhich  is  arsuperset  oftC+-H.  The?DME  simjplifies 
C++  library  routines,  such  as  setting  the  database  root-andicontroUing  ‘transactions,  by 
replacing  a  sequence  of  ■C++:cominands=with«a  single  DML  command. 


275  The  Magic  ¥LSI  Layout  Design  System 

Due  to-the  complexity  and  cost  associated  with  theidesign  andicreation  of  VESI  cir¬ 
cuits,  computer-assistedltoolsjare  essenti^.  Oneotthe  key  steps  in  the  circuit  development 
pfpcessfis  design  of  a  physic4  layout  ofithe  circuit  whicfecan  Ee  directly  implemented  on 
a  chip.  Tools  for  manipulating  and=verifying  this  design  are  necessary  to  keep  tfackiof  the 
numerous  components  and  connections  and  to  minimize  the  risk  ofSthe  chip  failing/after 
it 'has  been  manufactured.  One  such  tool  is-sthe  Magic  VLSI  dayout  system  whichi  was 
originaUy  developed  at  the  University  ofrCalifornia  in  Berkeley  withihe  latest  releaseiffom 
Digital-sEquipment  Corporation’s  Western  RelearchtLaboratoryin  1990. 

Bhe  purpose ‘.of  Magic  ds  touncrease  the  power  and  flexibility  of-previpus  layout 
editors.so-that  designs  ean  be«entered  quickly-and:  modified  easily.  (16)  Toiaccomplisfothis 
goal.  Magic  provides  basic  commands  foKcreating,  copying,  mo^fying,  andideletjng  circuit 
components  alongswith.capabiiitiesifor  autoniated  circuit  iroutihg  andicontihuous  checking 
ofsdesign  rules.  Circuits-  can-.ibe  cfeatedlcompletely  from^scratch  or  through  ihiera.rchical‘ 
inclusiph  of  any  number.of  sub-cpinponehts.  Eile  extraction  tools  .have  also  been  inc}uded= 
as=part'of  Magic  for  coinpatibility  withicircuit  testing  and  manufacfuringisystems.  (lO) 

To  improveiperformance  andfesimplify  the  designer’s  view^oLatcircuit,  Ma^c  imple¬ 
ments  some  uniqueffeatures.  The  geometricaUcpntents  ofta  circuit  are  represented  using  a 
technique  caUed  cornet’stitcHing.  In  thisltechhique,5axircuit  contains  a  numbewpfcofner- 
stitched  planes,  each  oflwhich  consists  of  a  niimber  pf  rectangular  stiles  fepr^enting  the 
physicalmaterial-tpsbe  included  in^the  actual  circuit,  These  tiles  areithe  fundamentaltdata 
units  represented  imthe  database.  Eachiflie  isBnkediin  itsilowerleft  cprnefsto  thpse  tifes  to 
itsdeffe  and  bottom;  Anpthefllink  jn  theiuppcr  right  corner  connects?  the  tiles  to  the?fight 
anddop.  Eigure  T  denronstrates  how  three  fljleddn  tijes?  (enclosed  with-SofidShne^  would  be 
stitcheddPgether  with  bjank=tiles‘(dashed'Iine4  in  a'single  plane.  Gpfher  stitching  permits 
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Figure  r.  Corner  stitching  ofttiles  in-a  plane  (15) 

searchtoperationsitb  beiperfdfmedsinore;efficiehtly'(il5);;Kowever,;iteratingithrpugh.all  tile's 
iiiia  ceUiinay.tfeqiure  traversing  amumbjr  of  ^ubceU^hiefarchiCs?  in  the  d^ab^; 

Ifi-  the  manufactiife  pf-.a  chip,  the  various  materiys  which  -make'*up  the  electrical^ 
c5mpofientsipfithe:chipsare:appliedHndayersiwith?masksiwhich<specify  exactlywhefe  each; 
material  wil|i:be  placed^  Many  circuit  dlsigmsystems  present  itheseimasksito -the  deligneh 
exactlya^  they  wiflf appear  gnithe  chip.  This  gives  the  de^ignerllittleiinfofmatiM  abd'utithe 
actual' electrical  function  of  the  design.  Magic,  however abstracts  these  mask  layerslinto  a 
style  referred;to  asr7offs,  The^;logsiare  similaf4p  a  symbolic  cifcuit'iayoutewhich*  a  designer 
uses.tpiundefstandithe:eiectrical;fuhctiPhality*pf  the  circuit.  The  primary4diffefence?is.that 
each  cpmpohent  is:seen*in-itsjactual  size  andllocatipn.  (fiS) 

216  Summary 

Based  on  the  chafacteristicsipf  engineering  designisystefns.ahd  theikey  components 
pfjthepbjecfcoriehtedcpmputingparadjgm,  pfejectrorienteddatabasemahagenient  systems; 
appear ‘welh  suitedidpr  supporting  itheseidesipi  sy^ems.  Some  attemptsihaveibeehimade 
tPidempnstfate  thetimpfovedbperfprmance=oftOOI)BMSsj  but’mpnetofithese  attempts  hal 
successfully  modeled'aitypical  designiapplicatiPn  tp  measure  this  pefforinance;.  ThelMagic 
layout-desigmsystemuses^acifcuitidesighirepfesentatipmwhichtisweTsuitedTPfian  objects 
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oriented  database  system.  The  ObjectStore  datable  rnanagementisystemds  one  of  the  few 
cominercially  aA^^able^OOlJBMSs  avajlable.  5t  supports? moshotthe  utihtiesiexpecled  of 
an  ob ject-orientedt  datcdjase  system  andiis  suitableTpr  iniplementatibn  dfithe  =Magic;|ayout 
systena?  Using  Magic  apd  QbjectStore,ithis  thesis^provides  aitypicMtdesign  applicatibn  for 
ineasuring  object-priented  database  pefformance. 
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HI.  Design  and  Implementation  of  Magic  Using  ObjeclStore 

3.1  Overview 

The  implementation  of  Magic  with  ObjeclStore  requires  application  of  recognized 
software  engineering  principles.  The  first  step  is  to  determine  the  design  of  the  Magic 
system  and  which  components  require  modification.  This  design  is  then  modified  so  that 
it  can  be  implemented  with  ObjectStore.  For  performance  measurement,  the  code  is  in¬ 
strumented  with  timing  commands  where  appropriate.  Testing  is  then  accomplished  to 
verify  functionality  and  to  compare  performance  with  the  original  Magic  system. 

3.2  Magic  Design  Recovery 

Magic  is  a  large  software  system  consisting  of  over  250,000  lines  of  C  source  code  in 
over  40  separate  U nix  directories.  To  ma.ximize  code  efficiency,  many  of  the  data  structures 
and  algorithms  are  extremely  complex,  often  using  obscure  C  language  characteristics. 
The  design  documentation  consists  of  a  maintaincr's  manual  with  a  brief  description  of 
the  directory  layout  and  functionality  along  with  in-line  comments  in  the  source  code.  As 
such,  understanding  the  system  organization  and  design  is  a  difficult  undertaking. 

In  approaching  a  design  recovery  of  the  Magic  software  system,  the  first  step  is  to 
review  the  existing  documentation.  This  review  reveals  a  combination  of  functional  and 
object  oriented  problem  decomposition.  The  object-oriented  modules,  such  as  the  window 
manager  and  databuse  manager,  encompass  all  data  structures  and  services  for  an  object 
completely  within  the  module.  Other  modules  like  plot,  plow,  and  wiring  include  all 
procedures  necessary  for  accomplishing  the  designated  function. 

Each  module  has  its  own  subdirectory  except  for  some  utility  and  other  miscella¬ 
neous  functions  which  are  grouped  together  into  combined  subdirectories.  To  simplify 
understanding  of  the  overall  Magic  system,  these  modules  have  been  grouped  into  “super- 
modules”  whicli  represent  the  main  services  provided  by  Magic.  Of  greatet  importance 
to  this  thesis  is  the  database  management  super-module.  Most  interfaces  to  the  Object- 
Store  database  management  system  will  take  place  within  this  module.  Figure  2  shows 
each  of  these  super  modules  and  indicates  whether  a  module  interfaces  with  the  database 


17 


management  module.  In  this  figure,  the  label  at  the  top  of  the  box  represents  the  super¬ 
module  name  and  the  lower  portion  of  the  box  lists  the  individual  modules  within  that 
super-module.  Lines  to  each  i^*  dividual  module  indicate  interaction  with  the  database 
manager. 

While  most  modules  interface  with  the  database  manager,  implementation  with  Ob- 
jectStore  affects  only  a  few  of  these  interfaces.  Most  of  the  ObjectStore  administration 
(such  as  opening  and  closing  the  database)  nmst  occur  within  the  main  module.  Since  the 
window  manager  does  all  window  manipulation  associated  with  displaying  a  circuit  that 
has  been  retrieved  from  the  database,  its  performance  is  closely  linked  with  the  database 
manager.  To  determine  the  effect  a  command  will  have  on  the  database,  and  to  ensure 
this  command  continues  to  have  the  same  effect  with  ObjectStore,  understanding  of  the 
command  interpreter  is  also  important.  Finally,  the  utilities  module  is  of  concern  since  it 
includes  functions  for  abstract  data  types  such  as  hash  tables  and  lists. 

Analysis  of  the  C  header  files  for  the  database  manager  reveals  the  primary  data 
structure  shown  in  Figure  3.  Here  an  object  is  represented  by  a  box  with  the  object 
name  in  the  top  section  of  the  box  and  its  attributes  in  the  lower  section.  Diamonds 
represent  relationships  between  objects.  The  key  component  of  a  Magic  circuit  is  the  cell 
definition  (CellDef ).  This  includes  descriptive  fields  such  as  the  cell  name,  associated  Jiip 
technology,  and  time  of  last  update.  It  also  includes  pointers  to  the  p’'  .les  which  contain 
the  geometrical  representations  in  the  cell;  a  pointer  to  a  list  of  labels  associated  with  the 
cell;  a  pointer  to  a  list  of  cell  instances  (referred  to  in  Magic  as  cell  uses)'  and  a  pointer 
to  a  hash  table  of  all  instances  of  other  cells  which  reference  the  cell.  Each  plane  also 
has  pointers  to  a  corner-stitched  list  of  tiles  which  are  contained  in  the  plane.  Normally 
ti_body  specifies  the  paint  in  the  tile;  however,  tiles  in  the  subcell  plane  include  a  list 
of  pointers  to  the  subcell  uses  which  overlap  the  tile  (CellTileBody).  All  cell  definitions 
currently  active  in  Magic  are  contained  in  dbCellDefTable,  a  hash  table  which  is  visible 
only  to  the  database  manager. 

To  better  understand  the  relationship  between  cell  definitions  and  cell  uses.  Figure  4 
provides  a  simplified  example.  Cells  A  and  B  each  represent  cells  that  have  cells  X  and 
Y  as  subcells.  The  cell  definition  of  X  is  named  CdX.  It  references  cell  use  CuX3  with  its 
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Figure  3.  Data  structure  for  Magic  cells 


cd_parents  pointer.  It  also  points  to  a  hash  table  which  only  includes  cell  use  CuXl.  This 
indicates  that  CdX  is  not  referenced  by  any  cells  other  than  itself.  Cell  use  CuX3  is  the 
cell  use  associated  with  cell  B.  The  cu.parent  pointer  to  cell  definition  CdB  shows  this 
relationship.  The  cu_def  pointer  in  CuX3  points  to  cell  definition  CdX,  of  which  CuX3  is  a 
specific  instance.  Each  cell  use  also  has  a  cujiextuse  pointer  which  points  to  the  next  cell 
use  associated  with  a  particular  cell  definition.  In  this  case,  CuX3  points  to  CuX2  which 
points  to  CuXl  where  the  list  terminates  with  a  null  pointer.  CuX2  represents  the  instance 
of  CdX  in  cell  A  and  CuXl  represents  the  instance  of  CdX  associated  with  cell  X.  Each  cell 
definition  always  has  an  instance  associated  with  itself.  Cell  definition  CdA  provides  a 
better  example  of  the  cdJLdHash  pointer.  In  CdA  this  points  to  a  hash  table  of  aU  cell  uses 
that  are  included  in  cell  A.  This  includes  an  instance  of  the  cell  itself  (CuAl)  as  well  as  each 
of  its  subcells  (CuXl  and  CuYl). 

While  the  basic  functionality  of  the  database  module  can  be  determined  from  the 
limited  documentation  in  existence  and  its  data  structures  can  be  determined  from  the 
header  files,  actual  understanding  of  the  call  hierarchy  and  effect  of  commands  can  only 
be  accomplished  by  tracing  the  path  of  input  commands  through  the  Magic  system.  Some 
additional  information  is  also  obtained  through  frequent  use  of  the  Unix  grep  and  calls 
commands.  The  functions  of  the  database  module  most  likely  to  be  affected  by  implemen¬ 
tation  with  ObjectStore  are  described  below.  The  source  code  files  associated  with  these 
functions  are  listed  in  parentheses. 

•  Create  and  delete  cell  definitions  and  cell  uses  (DBcellname.c). 

•  Create  and  maintain  the  cell  definition  table  (DBcellname.c). 

•  Write  and  read  cells  to  and  from  disk  (DBio.c). 

•  Create,  split,  join,  and  delete  cell  planes  and  tiles  (tile.c). 

If  the  database  module  was  truly  object-oriented,  design  recovery  would  end  here. 
Unfortunately,  many  modules  throughout  Magic  directly  access  the  data  structures  of 
the  database  module,  thereby  making  the  interface  less  well  defined.  For  instance,  the 
initialization  routines  in  many  modules  directly  access  planes  within  a  cell.  Similarly,  each 
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window  lias  a  cell  instance  associated  with  it  which  the  window  manager  modifies  without 
going  through  the  database  module. 

To  test  and  debug  the  database  module,  one  must  understand  the  data  flows  between 
the  window'  manager,  command  processors,  and  database  manager.  The  database  window 
manager  command  interpreter  (DBWcommands  function  in  program  DBWprocs .  c)  is  die  key 
procedure  in  this  process.  If  a  button  is  pressed,  the  current  button  handler  is  activated 
from  within  the  database  window  manager  to  interpret  the  button,  perform  the  desired 
processing,  and  update  the  window  as  appropriate.  If  a  text  command  is  entered,  it  is 
first  parsed  by  the  text  processor  {textio  module).  The  database  window  manager  then 
activates  the  selected  command  processor  to  accomplish  the  requested  processing.  Any 
updates  to  the  window  are  then  initiated  from  the  command  processor. 

3.3  Restructuring  of  Magic  Software  to  Work  with  ObjectStore 

For  this  thesis,  the  only  modifications  made  to  the  Magic  software  are  those  neces¬ 
sary  for  Magic  to  work  with  the  ObjectStore  database  management  system.  This  requires 
persistently  allocating  all  transient  database  structures  and  providing  an  entry  point  into 
the  ObjectStore  database.  In  addition,  the  ObjectStore  database  file  must  be  opened  and 
closed  and  transactions  must  be  specified  such  that  all  databcise  accesses  occur  within  a 
transaction.  This  first  phase  of  implementing  Magic  with  ObjectStore  requires  the  follow¬ 
ing  changes.  (A  complete  summary  of  all  modifications  to  the  Magic  software  is  contained 
in  the  OSmagic  Programmers’  Manual  (5)). 

•  Where  a  database  element  such  as  those  in  Figure  3  has  been  allocated  with  the 
procedure  MALLOC,  remove  the  MALLOC  and  replace  it  with  the  ObjectStore  Data 
Definition  and  Manipulation  Language  (DML)  persistent  new  command. 

/*  replace  MALLOC  with  ObjectStore  DHL  new 
* 

*  MALLOC (CellDef  *,  cellDef,  sizeof  (CellDef)); 

*/ 

cellDef  =  newCmagicdbl,  cellConfig)  CellDef; 
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Similarly,  where  a  database  element  is  deallocated  with  FREE,  remove  the  FREE  com¬ 
mand  and  replace  it  with  a  DML  persistent  delete  command. 

/*  replace  old  memory  deal3ocation  with  DML  delete 
* 

*  FREE  (celHJse->cu_id) ; 

*/ 

delete  cellUse->cu_id; 

•  Make  the  cell  definition  symbol  table  (dbCellDefTable)  the  entry  point  into  the 
database.  This  is  accomplished  by  declaring  it  as  a  persistent  variable. 

persistent<magicdbl>  osHashTable  *dbCGllDefTable  =  NULL; 

•  Declare  and  initialize  (open)  the  database  in  the  program  main .  c  and  include  the 
main  procedure  within  an  ObjectStore  transaction.  The  original  attempt  at  accom¬ 
plishing  this  was  to  enclose  the  contents  of  magicMain  (the  main  Magic  procedure) 
within  a  DML  do.transaction  statement;  however  the  main  Magic  procedure  is 
terminated  from  within  another  module,  thus  preventing  the  entire  main  procedure 
from  executing.  As  a  result,  the  do.transaction  statement  never  ends  and  no  data  is 
written  to  the  database.  Resolution  requires  separate  transactions  to  initialize  Magic 
and  another  transaction  (main.tx)  for  the  main  Magic  process.  Note  that  a  different 
format  is  used  for  the  main  transaction.  ObjectStore  allows  a  transaction  to  be  en¬ 
closed  within  the  do.transaction  statement  or  started  with  transaction:  :begin 
and  ended  with  transaction: : commit  (to  save  the  results  of  the  transaction)  or 
transaction: : abort  (to  restore  the  database  to  its  state  prior  to  the  transaction). 
Code  modifications  to  open  the  database  and  implement  ObjectStore  transactions 
are  shown  in  Figure  5. 

•  Close  the  database  and  commit  the  main  transaction  in  the  procedure  MainExit. 

transaction:  :conunit (main.tx) ; 
raagicdbl->close() ; 

In  an  object-oriented  Ci-f-  program,  implementation  of  these  changes  may  have  been 
rather  straightforward  and  uncomplicated.  Unfortunately,  Magic  is  not  such  a  program. 
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/*  Open  database  "/osmagic/Inagicdb^ ”  */ 

magicdbl  =  database:  :open("/osraagic/i:.agicdbl"  ,0,0664)  ; 

do_transaction()  { 

workspace: :set_current(user_ws) ; 

}  /*  end  of  transaction  */ 

/*  begin  initialization  transaction  *! 
do_transaction()  {. 

mainInitBeforeArgs(argc,  argv); 
mainDoArgs(argc,  argv); 
mainInitAfterArgsO ; 

}  /*  end  of  initialization  transaction  */ 

/*  begin  main  transaction  called  "main_tx"  */ 
main_tx  =  transaction: :begin(transaction: : update) ; 

TxDispatchC  (FILE  *)  NULL); 
mainFinishedO ; 

Figure  5.  Code  modifications  to  function  magicMain 

The  first  difficulty  is  that  Magic  is  written  in  C  rather  than  C++.  C++  was  designed 
to  be  compatible  with  C  (18);  however,  this  compatibility  is  not  complete.  ObjectStore 
has  a  C  library  interface,  but  this  does  not  allow  one  to  take  full  advantage  of  object- 
oriented  programming  techniques.  Any  program  which  contains  ObjectStore  DML  must  be 
compiled  with  the  DML  compiler.  This  compiler  is  a  slightly  modified  C++  compiler.  Thus 
all  procedures  in  a  program  containing  ObjectStore  DML,  whether  affected  by  ObjectStore 
or  not,  must  be  modified  for  compatibility  with  C++.  This  requires  type  specification  of 
all  function  parameters.  In  many  cases.  Magic  passes  function  pointers  as  parameters, 
wliich  complicates  type  specification.  Also,  for  a  C++  procedure  to  be  linked  with  a  C 
program,  the  linkage  must  be  specificaUy  defined  with  an  extern  "C"  type  specification  for 
the  function  declaration.  Thus,  all  of  the  forty  plus  header  files  contaimng  C++  function 
declarations  must  be  modified  to  include  the  extern  "C"  qualifier.  Tliis  is  accomplished  by 
defining  a  preprocessor  constant  of  _0SHAGIC  in  a  header  file  (osraagic.h  for  the  programs 
using  ObjectStore  DML).  Other  header  files  are  then  modifie  I  to  include  the  extern  "C" 
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#ifndef  _OSHAGIC 

/*  if  using  old  magic  code,  use  "C"  function  declarations  */ 

/*  Jacobs  02/08/91  */ 

extern  Plane  +TiNeHPlane() ; 
extern  void  TiFreePlaneO ; 
extern  Tile  *TiSplitX(); 
extern  Tile  *TiSplitY(); 

#else 

/*  use  function  declarations  modified  for  compatibility  with  C++  */ 
/*  Jacobs  02/08/91  */ 

extern  "C"  Plane  ♦TiNewPlaneCTile*,  CellConf ig*) ; 
extern  "C"  void  TiFreePlane (Plane*) ; 
extern  "C"  Tile  *TiSplitX(Tile*,  int); 
extern  "C”  Tile  *TiSplitY(Tile*,  int); 

#endif 


Figure  6.  Sample  header  file  modifications  from  tile.h 

qualifier  for  DML  programs  if  .OSMAGIC  is  defined  or  just  the  qualifier  extern  if  .OSHAGIC 
is  not  defined.  Figure  6  shows  modified  code  from  tile.h  which  demonstrates  the  changes 
required  for  each  header  file. 

Other  procedures  outside  of  the  database  module  also  must  be  modified  due  to  de¬ 
ficiencies  in  Magic’s  object-oriented  implementation.  Additional  storage  is  allocated  for 
a  cell  in  the  string  duplication  (strdup.c)  program  of  the  utilities  module.  A  persistent 
version  of  this  program  (osstrdup.ee)  is  required  for  any  string  duplication  withiu  the  cell 
structure.  The  cell  labeling  (DBlabel.c),  cell  painting  (DBpaint.e,  DBtiles.e),  and  cell 
subroutine  (DBeellsubr.e)  programs  also  allocate  cell  storage  wliich  must  be  persistent. 

Since  the  cell  symbol  table  is  used  as  a  database  entry  point,  it  must  also  be  per¬ 
sistently  allocated.  The  hash  table  abstract  data  type  (ADT)  (hash.c),  of  which  the  cell 
symbol  table  is  an  instance,  is  also  used  for  non-database  functions,  so  a  separate,  per¬ 
sistent  hash  table  ADT  (oshash.ee)  must  be  created  and  used  for  the  cell  symbol  table. 
This  symbol  table  only  uses  strings  as  keys,  so  the  C  union  in  the  original  hash  table 
ADT  can  be  replaced  with  a  string.  This  simplifies  DML  implementation  by  eliminating 
the  need  for  union  discriminant  functions. 
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The  maze  router  (mzrouter)  initialization  procedure  attempts  to  directly  access 
planes  within  a  cell.  The  first  time  the  initialization  procedure  is  run  on  the  database, 
the  cell  and  planes  become  persistently  allocated.  The  mzroutar  initialization  procedure 
must  then  be  modified  to  access  the  persistent  planes  by  traversing  the  cell  hierarchy. 

Modifications  up  to  this  point  have  been  necessary  for  Magic  to  work  with  persis¬ 
tently  allocated  structures  in  an  ObjectStore  database.  Previously  these  structures  were 
transiently  allocated  and  could  be  cleared  by  quitting  Magic  or  by  reading  the  cell  again. 
Persistent  allocation  eliminates  the  possibility  of  deleting  a  cell  or  removing  changes  that 
are  unwanted.  To  provide  these  functions  and  other  input/output  functions  in  a  manner 
similar  to  the  original  Magic  system,  ObjectStore’s  versioning  capabilities  are  required. 

Versioning  requires  definition  of  a  configuration  to  be  versioned  and  persistent 
allocation  of  workspaces  to  control  the  versions.  For  this  implementation  of  Magic,  the 
global  workspace  contains  the  latest  frozen  version  of  a  cell,  much  as  thj  flat  disk  file  does 
in  the  original  version  of  Magic.  New  cells  are  created  and  modified  in  the  user  workspace. 
The  user  woikspace  is  set  as  the  current  workspace  for  the  duration  of  the  Magi.,  program. 

The  obvious  choice  for  a  v<;r.sion  configuration  is  a  cell  definition  and  all  of  its  sub¬ 
components  and  subcells.  A  symbol  table  must  be  created  for  the  t-U  configurations  so 
that  each  cell  definition  can  be  associated  with  its  configuration.  Whenever  a  cell  is  read, 
it  is  checked  out  of  the  gh.J.a*  vorkspace  into  the  current  user  workspace.  Writing  a  cell 
requires  checking  the  cell  I  <  ,ck  into  the  global  workspace.  To  flush  a  cell,  the  version  in 
the  current  user  workspace  is  destroyed  and  the  old  version  is  :hecked  out  of  the  global 
workspace  to  replace  the  destroyed  version  in  the  user  workspace.  New  procedures  which 
search  the  configuration  symbol  table  i;nd  check  the  appropriate  configuration  in  or  out  of 
the  current  workspace  are  needed. 

Even  with  versioning,  some  commands  can  not  be  made  to  work  exactly  like  the 
original  Magic  system.  Both  the  write  and  save  command  write  a  cell  to  disk.  The  save 
command  allows  the  cell  to  be  saved  under  another  name.  Both  of  these  commands  allow 
further  modification  of  the  cell  after  writing.  These  commands  must  be  modified  to  work 
with  ObjectStore.  Save  will  check  the  cell  back  into  the  global  workspace,  but  will  allow 
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continued  editing  of  the  cell  by  checking  it  back  out.  Write  will  check  the  cell  into  the 
global  workspace  and  prohibit  further  editing. 

In  the  original  Magic,  cells  are  deleted  by  using  the  Unix  rm  command  external  to 
Magic.  This  is  not  possible  using  ObjectStore  so  the  new  command  remove  cellname  must 
be  added.  This  command  wiU  only  delete  a  cell  definition  if  it  is  not  used  by  any  other 
ceUs. 

S.4  Code  Instrumentation  for  Performance  Measurement 

To  compare  the  performance  of  Magic  with  and  without  ObjectStore,  a  method  must 
be  provided  for  measuring  this  performance.  The  Sun  operating  system  provides  profiling 
options  which  are  implemented  by  the  compiler.  This  profiling  provides  detailed  timing 
and  usage  statistics  on  every  function  in  Magic.  Unfortunately,  due  to  the  size  of  Magic, 
intexpretation  of  this  information  is  time  intensive  and  complicated.  Since  such  detailed 
information  is  not  necessary,  the  code  itself  is  instrumented  at  critical  points  to  measure 
only  that  information  which  is  essential  for  comparing  performance  of  the  two  versions  of 
Magic. 

All  commands  and  button  input  are  processed  through  the  command  interpreter 
module.  The  TxDispatch  function  in  the  program  txCommands.c  dispatches  all  Magic 
text  and  button  commands.  This  allows  timing  statistics  to  be  initiated  prior  to  calling 
the  command  processor  or  button  handler  and  terminated  immediately  following  the  call. 
Similarly,  initialization  statistics  are  measured  by  surrounding  Magic’s  initialization  pro¬ 
cedures  with  statistical  commands.  A  program  (CommandStats.c)  is  written  for  gathering 
statistics.  CommandStats  makes  calls  to  the  Unix  functions  getrusage  and  gettimeofday 
and  calculates  processing  time  and  wall  clock  time.  This  information  is  printed  to  a  file 
along  with  the  command  being  processed  or  the  button  handler  in  use. 

3.0  Testing 

3.5.1  Testing  Magic  Functionality.  If  ObjectStore  is  to  replace  the  existing  data¬ 
base  management  system  of  Magic,  it  must  maintain  complete  functionality  of  the  original 
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system.  To  exhaustively  test  the  functionality  of  a  system  the  size  of  Magic  would  require 
an  inordinate  amount  of  time.  Fortunately,  since  the  purpose  of  this  thesis  is  only  to 
demonstrate  the  feasibility  of  ObjectStore,  such  exhaustive  testing  is  not  necessary.  In¬ 
stead,  a  simple,  sound  test  of  the  database  functions  along  with  limited  testing  of  the  other 
Magic  functions  should  be  adequate. 

Part  of  the  limited  documentation  of  Magic  is  a  tutorial  wliich  walks  the  new  user 
through  aU  of  the  basic  commands  that  are  available.  This  tutorial  is  the  basis  of  the 
functionality  testing  for  Magic.  Where  database  commands  are  used  such  as  save,  flush, 
and  load,  an  attempt  is  made  to  test  all  classes  of  input  parameters  (e.g.  save  is  tested 
with  no  parameters,  with  the  same  cell  name  as  a  parameter,  and  with  a  new  cell  name  as 
a  parameter).  Since  few  new  functions  have  been  added  and  most  of  the  Magic  modifica¬ 
tions  are  simply  conversions  from  C  to  ObjectStore  DML,  little  should  change  in  Magic’s 
functionality.  Any  errors  introduced  as  a  result  of  the  changes  should  be  significant  enough 
to  be  caught  by  the  above  tests.  In  addition,  since  performance  testing  concentrates  on  the 
database  (see  the  following  section),  these  tests  serve  to  further  validate  the  functionality. 

3.5.2  Performance  Testing.  Performance  testing  compares  the  differences  in  access 
time  between  Magic  implementation  using  ObjectStore  and  the  original  implementation 
using  flat  Unix  files.  This  testing  must  measure  Magic  performance  during  a  typical  user 
session  along  with  concentrated  testing  of  the  database  functions  of  Magic.  A  typical  user 
session  (as  used  at  the  Air  Force  Institute  of  Technology)  does  not  require  many  database 
accesses.  This  is  likely  due  to  the  difficulty  of  accomplisliing  common  database  functions 
(such  as  searching  for  an  existing  cell)  and  the  experimental  nature  of  educational  research 
which,  leads  to  circuits  built  entirely  from  scratch.  Since  a  typical  user  session  does  not  ad¬ 
equately  test  the  database  capabilities,  performance  comparisons  are  also  conducted  using 
the  IlyperModel  Benchmark  (see  Section  2..3.1)  guidelines.  The  HyperModel  Benchmark 
lists  six  areas  wliich  are  important  for  measuring  database  performance  lookup  and 
retrieval,  traversal,  insertion,  sequential  scan,  closure  operations,  and  opening  and  closing 
of  the  database. 
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All  performance  testing  is  accomplished  with  existing  Magic  commands.  As  such, 
some  of  the  six  areas  above  may  be  only  partially  tested.  Use  of  existing  commands  is 
necessary  so  ObjectStore  performance  can  be  directly  compared  to  the  existing  flat  file 
structure.  The  ObjectStore  database  is  loaded  in  advance  with  all  Magic  cells  in  a  specific 
search  path,  so  that  the  search  space  is  rougldy  equivalent  with  that  of  the  Unix  directories. 

Performance  testing  is  accomplished  on  two  existing  cells.  On«-  cell  contains  87 
subcells  with  eight  levels  of  nesting  and  the  other  cell  contains  two  subcells  with  one 
level  of  nesting.  The  various  Magic  commands  for  measuring  the  benchmark  criteria  are 
discussed  below. 

•  Look  up  and  retrieve  an  object  from  the  database.  The  load  cellname  command 
searches  the  database  until  it  finds  the  specified  cell  and  then  displays  it  in  the 
selected  window.  If  the  cell  has  any  subcells,  these  are  not  initially  displayed. 

•  Traverse  pointer  hierarchy.  The  expand  command  loads  and  displays  all  of  the  sub¬ 
cells  in  a  selected  area  of  the  root  cell.  When  the  entire  cell  is  selected,  all  of  the 
subcell  pointers  are  dereferenced  and  the  subcells  displayed. 

•  Insert  an  item  into  the  database.  The  gelcell  cellname  command  loads  a  subcell 
from  the  database  and  creates  a  new  instance  of  that  cell  in  the  root  cell.  The  load 
command  without  a  specified  cell  creates  a  new  cell  definition  in  the  database.  With 
the  non-persistent  version  of  the  database,  the  new  cell  definition  or  instance  is  not 
actually  created  until  the  cell  is  saved;  therefore,  the  time  to  write  modified  cells  to 
disk  must  be  included  in  the  comparison  with  the  ObjectStore  version. 

•  Closure  operations.  In  normal  operation,  the  Magic  design  rule  checker  runs  in  the 
background.  To  test  closure,  however,  the  design  rule  checker  is  turned  off,  j.  subcell 
is  added  on  top  of  the  existing  cell,  and  the  design  rule  checker  is  run  on  the  entire 
cell. 

•  Sequential  Scan.  Since  no  use  is  made  of  ObjectStore  collections,  this  aspect  of  the 
database  benchmark  is  not  tested. 
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•  Database  initialization.  Since  the  existing  Magic  sj'stem  has  no  database,  this  ^  jnch- 
mark  can  not  be  directly  compared;  however,  the  tests  are  still  run  and  compared 
based  on  the  overall  time  to  initialize  Magic. 


3.6  Summary 

The  size  and  comple.xity  of  Magic  presents  a  difRcult  system  to  understand  and  mod- 
ifj.  Since  Objects  tore  is  written  to  take  adv-antage  of  the  object-oriented  characteristics 
of  C-f  -f.  Magic’s  imperfect  object-oriented  programming  structures  and  its  use  of  obscure 
C  programming  routines  increase  the  difficulty  of  converting  it  to  ObjcctStore.  Since  t..e 
original  Magic  has  no  database  management  system  whatsoever,  performance  testing  is 
complicated  by  the  inability,  in  many  cases,  to  directly  compare  the  ObjectStorc  version  of 
Magic  with  the  original  Magic  version.  Many  of  these  difficulties  are  overcome  with  careful 
implementation  of  ObjectStore  utilities  and  with  selective  testing  using  Magic  commands 
in  a  well  prepared  test  environment. 


IV.  Results  Analysis 


4.1  Overview 

The  primary  objective  of  this  thesis  is  to  show  that  an  object-oriented  database 
can  provide  the  performance  and  functionality  necessary  to  support  a  computer-aided 
design  tool.  By  careful  application  of  ObjectStore  utilities,  complete  functionality  of  the 
Magic  VLSI  circuit  layout  system  has  nearly  been  obtained.  This  chapter  compares  the 
relative  performance  of  Magic  as  implemented  with  ObjectStore  to  the  original  flat  file 
data  management  system.  The  chapter  also  points  out  the  difficulties  encountered  while 
converting  the  complex  C  code  of  Magic  to  work  with  the  complicated,  object-oriented 
data  management  facilities  of  ObjectStore. 

4.2  Performance  Comparison  of  ObjectStore  and  Flat  Data  Files 

The  performance  requirements  of  a  complex  engineering  design  system  such  as  Magic 
are  immense.  To  satisfy  these  requirements,  a  database  management  system  must  perform 
nearly  as  well  or  better  than  a  flat  file  data  management  system.  To  compare  the  per¬ 
formance  of  Magic  using  ObjectStore  to  Magic’s  performance  using  its  original  flat  file 
system,  the  performance  tests  described  in  Section  3.5.2  were  accomplished  using  two 
different  Magic  databases. 

drfm  This  database  consists  of  110  objects  (i.e.,  cell  definitions)  and  1861  different  in¬ 
stances  (i.e.,  cell  uses)  of  these  objects.  There  are  over  78,000  fundamental  data 
items  (i.e.,  tims)  at  the  lowest  level  of  the  object  hierarchy.  This  database  weis  tested 
using  cell  drfmchip  with  87  subcells  and  eight  levels  of  nesting.  The  Magic  display 
of  this  cell,  with  all  subcells  completely  expanded,  appears  in  Figure  7. 

tutorial  This  database  contains  70  objects  and  103  different  instances.  There  are  nearly 
9300  fundamental  data  items  at  the  lowest  level  of  the  object  hierarchy.  Testing  was 
accomplished  using  cell  tut4a  which  contains  two  subceUs  and  one  level  of  nesting. 
Figure  8  shows  the  Magic  display  of  the  tiles  and  subcell  structure  of  this  cell. 
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Figure  8.  Magic  display  of  cell  tut4a 
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The  results  of  the  performance  tests  are  shown  in  Tables  2  and  3.  Raw  performance 
test  results  are  contained  in  Appendix  A.  The  results  shown  in  Tables  2  and  3  represent 
averages  of  all  valid  results  obtained  for  each  command.  For  more  accurate  comparison 
with  ObjectStore,  the  resources  necessary  for  writing  all  modified  cells  to  disk  are  added 
10  the  performance  results  for  the  insertion  and  closure  tests. 

For  the  drfmchip  cell,  instance  insertion  and  closure  are  tested  on  a  subceU  nested 
four  levels  deep  in  the  hierarchy  (bigjiandmux)  and  on  a  subcell  nested  eight  levels  deep 
(mcelllO).  There  are  16  instances  of  the  big_nandmux  subcell  and  6144  instances  of  the 
mcelllO  subcell.  Between  these  two  levels  of  nesting,  the  time  difference  to  accomplish 
instance  insertion  and  closure  was  considerable  (See  Table  4).  The  average  of  these  two 
different  levels  is  used  for  comparison  in  Table  2.  Instance  insertion  and  closure  are  tested 
on  a  subceU  nested  only  one  level  deep  in  the  tut4a  cell.  There  are  only  eight  instances  of 
this  subcell. 

Testing  of  the  drfm  database  was  accomplished  with  ObjectStore  cache  sizes  of  both 
640  and  2048  sectors.  The  640  sector  cache  worked  more  quickly  for  look  up  and  retrieval, 
traversal,  initialization,  and  object  insertion.  These  are  the  results  shown  in  Table  2. 
Similarly,  the  results  for  the  2048  sector  cache  are  used  for  instance  insertion  and  closure. 
All  ObjectStore  results  for  the  tutorial  database  were  obtained  with  a  cache  size  of  2048 
sectors. 

The  results  for  the  different  cache  sizes  are  summarized  in  Table  5.  Instance  and 
closure  results  in  tliis  table  are  based  on  the  subcell  bigmandmux  which  is  nested  four 
levels  deep.  Neither  size  of  cache  performs  better  for  all  test  cases.  Optimal  cache  size  will 
depend  on  which  databcise  utilities  are  more  commonly  used. 

The  commands  used  for  performance  testing  fall  into  three  different  categories.  Those 
used  for  look  up  and  retrieval  and  hiei-archy  traversal  require  reading  from  the  database.  In 
the  original  version  of  Magic,  Insert  and  closure  commands  are  performed  entirely  within 
memory.  For  this  reason,  the  resources  necessary  to  write  to  disk  all  cells  modified  by 
these  commands  are  added  to  the  results  in  Tables  2  and  3.  Initialization  is  a  combination 
of  reading  and  writing  from  the  database  and  initializing  memory.  In  general,  Object- 
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Criteria  Tested 

Resource 

Data  Management  System 

Percent 

Command  Used 

Measured 

Flat  File 

Change 

Look  up/retrieve 

CPU  time  (seconds) 

0.05 

-17 

load  drfmchip 

Elapsed  time  (seconds) 

0.33 

-H75 

Page  Faults  with  I/O 

0 

-00 

Page  Faults  without  1/ 0 

36 

-f800 

Disk  Blocks  In 

0 

-00 

Disk  Blocks  Out 

0 

0 

0 

Hierarchy  Traversal 

CPU  time  (seconds) 

6.62 

1.54 

-76 

expand 

Elapsed  time  (seconds) 

9.32 

4.37 

-53 

Page  Faults  with  I/O 

89 

0 

-00 

Page  Faults  without  I/O 

733 

380 

-48 

Disk  Blocks  In 

91 

0 

-00 

Disk  Blocks  Out 

3 

0 

-00 

Insert  (object) 

CPU  time  (seconds) 

0.03 

0.02 

-50 

load  test 

Elapsed  time  (seconds) 

0.124 

0.040 

-68 

Page  Faults  with  I/O 

0 

0 

0 

Page  Faults  without  I/O 

13 

23 

-1-77 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

6 

0 

-00 

Insert  (instance) 

CPU  time  (seconds) 

1.36 

0.22 

-84 

getcell  test 

Elapsed  time  (seconds) 

2.63 

0.24 

-91 

Page  Faults  with  1/ 0 

1 

0 

-00 

Page  Faults  without  I/O 

112 

15 

-87 

Disk  Blocks  In 

1 

0 

-00 

Disk  Blocks  Out 

70 

0 

-00 

Closure 

CPU  time  (seconds) 

52.19 

193.42 

-1-271 

drc  catchup 

Elapsed  time  (seconds) 

53.98 

197.66 

-h266 

Page  Faults  with  I/O 

7 

2 

-71 

Page  Faults  without  I/O 

136 

151 

+11 

Disk  Blocks  In 

1 

0 

-00 

Disk  Blocks  Out 

70 

0 

-00 

Initialization 

CPU  time  (seconds) 

5.74 

5.86 

+2 

Elapsed  time  (seconds) 

10.71 

15.21 

+42 

Page  Faults  with  I/O 

82 

28 

-66 

Page  Faults  without  I/O 

203 

493 

+143 

Disk  Blocks  In 

13 

8 

-38 

Disk  Blocks  Out 

1 

2 

+100 

Table  2.  Benchmark  performance  results  for  drfm  database 
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Criteria  Tested 
Command  Used 


Resource 

Measured 


Data  Management  System  Percent 
Flat  File  ObjectStore  Change 


Look  up  and  retrieve 
load  tut^a 

CPU  time  (seconds) 
Elapsed  time  (seconds) 
Page  Faults  with  I/O 

Page  Faults  without  I/O 
Disk  Blocks  In 

Disk  Blocks  Out 

0.01 

0.047 

1 

6 

0 

0 

0.03 

0.037 

0 

30 

0 

0 

+200 

-21 

-00 

+400 

0 

0 

Hierarchy  Traversal 

CPU  time  (seconds) 

0.04 

0.02 

-50 

expand 

Elapsed  time  (seconds) 

0.0788 

0.0252 

-68 

Page  Faults  with  I/O 

1 

0 

-00 

Page  Faults  without  I/O 

3 

6 

+100 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

0 

0 

0 

Insert  (object) 

CPU  time  (seconds) 

■HI 

0.017 

-15 

load  test 

Elapsed  time  (seconds) 

0.026 

-84 

Page  Faults  with  I/O 

■■I 

0 

0 

Page  Faults  without  I/O 

13 

16 

+23 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

7 

0 

-00 

Insert  (instance) 

CPU  time  (seconds) 

0.060 

0.013 

-78 

getcell  test 

Elapsed  time  (seconds) 

0.532 

0.029 

-95 

Page  Faults  with  1/ 0 

0 

0 

0 

Page  Faults  without  I/O 

14 

1 

-93 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

22 

0 

-00 

Closure 

CPU  time  (seconds) 

0.58 

2.00 

+245 

drc  catchup 

Elapsed  time  (seconds) 

1.05 

2.03 

+93 

Page  Faults  with  I/O 

0 

0 

0 

Page  Faults  without  I/O 

24 

6 

-75 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

22 

0 

0 

Initialization 

CPU  time  (seconds) 

5.66 

5.82 

+3 

Elapsed  time  (seconds) 

8.53 

9.91 

+16 

Page  Faults  with  I/O 

14 

4 

-71 

Page  Faults  without  I/O 

299 

514 

+72 

Disk  Blocks  In 

2 

4 

+100 

Disk  Blocks  Out 

1 

1 

0 

Table  3.  Benchmark  performance  results  for  tutorial  database 
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Criteria  Tested 

Resource 

Level  of  Nesting 

Percent 

Command  Used 

Measured 

4  (  bigjicmdmux) 

Change 

Insert  (instance) 

CPU  time  (seconds) 

0.41 

0.022 

-95 

getcell  test 

Elapsed  time  (seconds) 

0.45 

0.027 

-94 

Page  Faults  with  I/O 

1 

0 

-00 

Page  Faults  without  I/O 

29 

1 

-97 

Closure 

CPU  time  (seconds) 

368.61 

18.23 

-95 

drc  catchup 

Elapsed  time  (seconds) 

376.75 

18.56 

-95 

Page  Faults  with  I/O 

3 

2 

-33 

Page  Faults  without  I/O 

251 

51 

-80 

Table  4.  ObjectStore  performance  at  two  different  levels  of  subcell  nesting 

Store  had  better  response  time  than  Magic’s  original  data  management  system  for  those 
commands  with  frequent  database  access  relative  to  total  processing  time. 

ObjectStore’s  performance  varies  most  significantly  with  the  closure  command  (i.e., 
drc  catchup).  To  understand  why,  more  insight  into  the  design  rule  checker  {drc)  is  required. 
The  design  review  checker  applies  rules  from  a  file  of  over  500  lines  to  each  tile  in  the 
cell.  Hierarchical  designs  are  checked  by  ensuring  the  cell  alone  is  consistent,  and  that 
the  combination  of  the  cell  and  all  of  its  subcells  is  consistent  (14).  This  may  require 
traversing  the  cell  hierarchy  a  number  of  times  to  complete  the  design  rule  checking;  thus, 
small  discrepancies  in  response  time  are  multiplied  into  large  differences  such  as  those 
shown  in  Tables  2  and  3. 

The  design  rule  checker  usually  runs  in  the  background  because  of  the  large  amount  of 
processing  it  requires  (14).  It  limits  its  checks  to  those  cells  which  are  currently  in  memory; 
other  cells  are  checked  the  next  time  they  are  read  into  memory.  This  allows  incremental 
application  of  design  rules  to  the  cell  and  eliminates  the  need  to  process  the  entire  cell  at 
once.  Since  the  ObjectStore  version  of  Magic  extends  memory  to  include  database  items 
which  are  on  the  disk,  it  always  appears  as  if  the  entire  database  is  in  memory;  thus,  the 
design  rule  checker  checks  all  cells  in  the  database.  Because  of  these  variations  in  virtual 
memory,  valid  comparisons  can  only  be  made  with  the  entire  cell  resident  in  main  memory. 

The  Objev  tStore  database  required  considerably  more  disk  space  than  Unix  flat  files 
(see  Table  C).  Both  ObjectStore  and  Magic  add  overhead  to  the  ObjectStore  database 
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Criteria  Tested 

Resource 

Cache  Size  (sectors) 

Command  Used 

Measured 

640 

2048 

Look  up/retrieve 

CPU  time  (seconds) 

0.05 

0.07 

+40 

load  drfmchip 

Elapsed  time  (seconds) 

0.33 

0.35 

+6 

Page  Faults  with  1/ 0 

0 

0 

0 

Page  Faults  without  1/  0 

36 

43 

+19 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

0 

0 

0 

Hierarchy  Traversal 

CPU  time  (seconds) 

1.54 

1.61 

+4 

expand 

Elapsed  time  (seconds) 

4.37 

5.91 

+35 

Page  Faults  with  I/O 

0 

0 

0 

Page  Faults  without  I/O 

380 

467 

+23 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

0 

0 

0 

Insert  (object) 

CPU  time  (seconds) 

0.022 

0.021 

-4 

load  test 

Elapsed  time  (seconds) 

0.040 

0.053 

+32 

Page  Faults  with  I/O 

0 

0 

0 

Page  Faults  without  I/O 

23 

20 

-13 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

0 

0 

0 

Insert  (instance) 

CPU  time  (seconds) 

0.05 

0.02 

-60 

getcell  test 

Elapsed  time  (seconds) 

0.077 

0.027 

-65 

Page  Faults  with  I/O 

1 

0 

-00 

Page  Faults  without  I/O 

10 

1 

-90 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

0 

0 

0 

Closure 

CPU  time  (seconds) 

23.48 

18.23 

-22 

drc  catchup 

Elapsed  time  (seconds) 

23.87 

18.56 

-22 

Page  Faults  with  I/O 

2 

2 

0 

Page  Faults  without  1/  0 

20 

51 

+155 

Disk  Blocks  In 

0 

0 

0 

Disk  Blocks  Out 

0 

0 

0 

Initialization 

CPU  time  (seconds) 

5.86 

6.02 

+3 

Elapsed  time  (seconds) 

15.21 

15.47 

+2 

Page  Faults  with  I/O 

28 

54 

+100 

Page  Faults  without  I/O 

493 

481 

-2 

Disk  Blocks  In 

8 

13 

+62 

Disk  Blocks  Out 

1 

2 

+100 

Disk  Usage  (kbytes) 

724 

4882 

+574 

Table  5.  ObjectStore  performance  comparison  with  two  different  cache  sizes 
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Data  Item 

Size  in  Kbytes 

Percent 

Change 

Flat  File 

ObjectStore 

tutorial  database 

58 

713 

+1129 

drfmchip  database 

724 

4882 

+574 

initialized  database  (empty) 

0 

147 

+CO 

test  object  &  instance 

0.081 

2.3 

+2740 

Table  6.  Comparison  of  ObjectStore  and  Unix  flat  file  disk  usage 


which  is  not  saved  in  the  Unix  file  representation.  For  Magic  this  overhead  is  approximately 
50  kilobytes.  The  ObjectStore  overhead  varies  with  the  total  size  of  the  database.  With  no 
data  other  than  the  Magic  and  ObjectStore  overhead  in  the  database,  the  total  database 
size  is  nearly  150  kilobytes.  In  addition,  ObjectStore  holds  the  entire  data  structure  for 
each  cell  in  memory.  This  includes  pointers  and  empty  hash  table  buckets.  The  Unix 
files  only  contain  the  contents  of  the  cell  data  structure.  Because  of  the  large  amount  of 
overhead  associated  with  ObjectStore,  the  difference  is  disk  usage  is  more  significant  for 
smaller  data  items. 

y,.3  Conversion  to  ObjectStore 

One  of  the  objectives  of  this  thesis  was  to  show  that  conversion  of  a  design  system  to 
an  object-oriented  database  is  a  cost-effective  venture.  If  this  new  technology  is  to  replace 
existing  design  systems,  system  managers  must  be  convinced  that  the  benefits  of  using 
a  database  will  outweigh  the  costs  of  conversion.  While  performance  is  one  of  the  key 
issues  in  this  decision,  there  are  a  number  of  benefits  (as  discussed  in  Chapter  1)  and  costs 
associated  with  converting  to  a  database  management  system. 

4-3.1  Problems  Encountered.  Due  to  the  size  and  complexity  of  Magic,  and  the 
intricacies  of  ObjectStore,  a  number  cf  difficulties  were  encountered  during  the  conversion 
process.  These  difficulties  were  further  aggravated  by  the  immaturity  of  the  ObjectStore 
database  system  and  the  lack  of  documentation  for  Magic. 

Implementation  of  ObjectStore’s  versioning  capability  presented  tlie  only  problem 
which  could  not  be  resolved.  The  configuration: : of  (oiject)  command  is  designed  to 
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return  a  pointer  to  the  configuration  of  the  object  specified.  In  a  number  of  places  this 
pointer  is  then  used  to  allocate  a  subobject  in  the  same  configuration  as  the  object.  The 
sequence  of  command  is  as  follows: 

cellConfig  =  configuration: :of(cellDef) ; 
cellUse  =  newCmagicdbl,  cellConfig)  CellUse; 

ObjectStore  fails  when  attempting  to  allocate  the  subobject.  No  fix  is  currently  available 
for  this  problem,  so  versioning  does  not  work  with  the  current  ObjectStore  implementation 
of  Magic.  This  prevents  a  circuit  designer  from  backing  out  of  cell  modifications  —  once 
a  cell  is  changtu,  the  change  is  reflected  permanently  in  the  ObjectStore  database. 

Another  problem  area  stems  from  the  incompatibility  of  C  and  C++.  In  theory,  C++ 
is  designed  to  be  a  superset  of  C  (18).  While  this  may  be  true  in  a  C  program  that  is  very 
well  designed  and  coded,  in  reality  C  allows  many  structures  that  are  not  compatible  with 
C++.  Wliile  Magic  is  a  rather  well  designed  system,  its  size  and  the  complex  programming 
structures  which  it  uses  to  maximize  efficiency  have  led  to  code  which  is  unstructured  and 
difficult  to  trace.  Some  common  problems  include  functions  used  without  being  previously 
declared,  data  types  used  in  header  files  that  are  declared  in  a  separately  included  header 
file,  and  functions  with  different  types  of  parameters  being  passed  as  parameters  to  another 
function.  Since  C++  has  much  stricter  type  checking,  these  problems  had  to  be  resolved  if 
the  program  included  any  ObjectStore  DML  commands  wluch  required  the  C++  compiler. 

While  not  directly  related  to  compatibility  between  C  and  C++,  the  ability  to  cast 
types  in  C  presents  significant  problems.  Magic  uses  this  capability  extensively.  In  one 
particular  instance,  ti.body  is  declared  as  a  char;  however,  to  handle  subceUs  within  a 
plane,  a  list  of  pointers  to  CellUse  is  cast  to  this  variable.  Initially,  Magic  sets  the  ti_body 
field  to  a  char.  If  ObjectStore  encounters  a  char  value  when  it  is  expecting  a  persistent 
pointer,  it  is  unable  to  dereference  the  pointer  and  the  program  aborts.  Such  errors  are 
very  difficult  to  trace  due  to  the  use  of  type  casting. 

Many  difficulties  were  encountered  due  to  peculiarities  of  the  ObjectStore  DML. 
Those  which  were  hardest  to  resolve  are  listed  below. 
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•  Inconsistency  of  schemas.  If  the  database  schema  is  modified,  the  old  database  is  no 
longer  valid  for  that  application  (16).  A  procedure  must  be  made  for  converting  the 
old  data  to  match  the  new  schema,  or  the  data  is  lost. 

•  Incompatibility  of  persistent  types  with  C.  Persistent  types  have  an  extra  level  of 
indirection  which  must  be  accounted  for  if  using  them  in  a  C  program  (16).  Ob- 
jectStore  also  uses  a  persistent  dereferencing  type  which  is  not  compatible  with  the 
C  compiler.  This  requires  all  C  programs  to  access  persistent  data  types  through  a 
C++  interface. 

•  Databases  and  persistent  database  entry  points  must  be  declared  at  a  global  level. 
Since  Magic  is  broken  into  a  number  of  subdirectories,  it  is  unclear  at  exactly  what 
level  these  declarations  should  occur.  This  was  resolved  by  declaring  them  at  file 
level  in  any  directory  and  including  an  extern  declaration  in  a  header  file. 

•  When  using  versioning,  the  effects  of  configuration:  iforget  are  unclear.  This 
command  should  remove  the  specified  version  from  the  current  workspace  (12);  how¬ 
ever,  this  does  not  happen  when  the  versioned  object  has  just  been  created  and  exists 
in  no  other  workspace.  The  configuration: :  destroy  .vers  ion  command  was  used 
instead.  To  be  able  to  destroy  a  version,  however,  the  configuration  must  have  been 
previously  frozen  in  some  workspace.  This  is  accomplished  by  first  checking  any 
new  configuration  into  the  global  workspace  before  checking  it  back  out  to  make 
modifications. 

•  A  discriminant  function  is  required  when  using  a  union  (12).  No  explanation  is 
given  on  what  this  function  should  do  and  when  it  should  be  called.  To  eliminate 
the  associated  complexities,  the  imion  was  removed  as  it  was  no  longer  necessary  for 
the  updated  Magic  program. 

•  When  more  data  is  read  into  memory  than  ObjectStore  can  manage,  it  attempts  to 
evict  a  page  from  memory  causing  an  exception  which  crashes  Magic.  To  overcome 
this  problem  when  testing  drfmchip,  the  cache  size  had  to  be  manually  increased  to 
2048  sectors. 
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Most  of  the  facilities  discussed  above  are  included  in  the  ObjectStore  documentation, 
but  inadequate  explanation  of  their  purpose  and  implementation  is  given.  The  documen¬ 
tation  often  tells  how  to  implement  an  ObjectStore  function  with  no  explanation  as  to  why 
it  is  done  that  way.  As  a  consequence,  when  something  must  be  done  different  for  a  specific 
application,  it  is  difficult  to  make  the  adaptation.  An  example  is  the  Makefile  structure 
for  Magic.  Magic  has  a  separate  Makefile  for  each  subdirectory.  This  Makefile  compiles 
each  program  in  the  subdirectory  and  links  the  object  files  into  a  composite  object  file  for 
the  entire  subdirectory.  Each  subdirectory  object  file  is  then  linked  together  for  the  Magic 
executable.  The  description  of  ObjectStore  Makefiles  assumes  all  object  and  source  code 
is  in  one  directory  (11).  The  solution  was  simple  —  to  only  use  the  ObjectStore  linker 
for  the  executable  and  not  for  each  individual  subdirectory  --  but  many  hours  of  analysis, 
trial  and  error,  and  consultation  with  the  ObjectStore  programmers  were  required  before 
the  problem  was  resolved. 

Another  significant  difficulty  with  the  documentation  occurs  when  using  the  Object- 
Store  DML.  Even  though  this  is  the  primary  language  for  ObjectStore,  the  ObjectStore 
User  Guide  deals  primarily  with  the  ObjectStore  C-h+  interface  library.  In  many  cases 
the  DML  replaces  multiple  library  calls,  thus  simplifying  the  programming  and  subsequent 
maintenance.  Only  brief  descriptions  of  these  DML  commands  are  given,  however,  with 
few  examples  and  little  correlation  to  the  functions  performed  by  the  library  interface. 

4-3.2  Effort  Required.  This  thesis  implements  a  minimal  database  version  of  Magic. 
Changes  were  made  to  replace  the  original  flat  file  structure  with  an  ObjectStore  database 
while  maintaining  the  same  functionality.  No  attempt  was  made  to  take  full  advantage  of 
ObjectStore ’s  other  features.  The  time  .spent  on  this  conversion  is  broken  down  in  Table  7. 
The  estimates  in  this  chart  are  based  on  the  perceived  difficulty  of  each  process  and  the 
total  time  available  for  the  conversion. 

As  reflected  in  this  table,  the  conversion  to  ObjectStore  took  longer  than  expected. 
Since  C  constructs  are  supposed  to  be  compatible  with  C++,  the  only  code  conversions 
expected  were  those  necessary  for  the  ObjectStore  DML.  The  many  other  conversions 
which  were  actually  required  had  a  significant  impact  on  the  time  required  to  make  Magic 
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Table  7.  Man  days  spent  converting  Magic  to  work  with  ObjectStore 


work  with  ObjectStore  and  its  C-f-+  compiler.  The  other  major  deviation  in  time  is 
that  required  for  implementing  ObjectStore  versions.  This  is  an  extremely  challenging 
ObjectStore  utility  and  the  documentation  is  somewhat  limited.  In  some  cases,  such  as 
configuration:  :forget,  the  versioning  commands  do  not  work  exactly  as  the  documen¬ 
tation  describes  them.  In  other  instances,  for  example,  when  Magic  creates  an  instance  of 
a  cell  for  a  window  or  initializes  a  plane  for  a  tool  like  the  circuit  router,  it  was  difficult  to 
determine  what  version  the  new  plane  or  cell  instance  should  be  in. 

4.4  Summary 

Performance  tests  were  accomplished  for  six  benchmark  areas  using  the  Objectstore 
version  and  the  original  version  of  Magic.  While  problems  were  encountered  during  the 
implementation  of  Magic  with  ObjectStore,  the  implementation  was  complete  enough  to 
compare  performance  of  the  two  data  management  systems.  The  problems  encountered 
range  from  failures  of  ObjectStore  procedures  to  difficulties  in  making  C  code  compatible 
with  the  Objectstore  DML  compiler.  Some  problems  were  further  complicated  by  inade¬ 
quacies  in  Objectstore  documentation.  These  difficulties  are  reflected  in  the  effort  which 
was  required  to  convert  Magic  to  use  the  ObjectStore  database  management  system. 
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V.  Conclusions  and  Recommendations 


5.1  Overview 

This  chapter  summarizes  the  activities  necessary  for  implementing  and  testing  Magic 
with  the  ObjectStore  database  management  system.  The  results  presented  in  Chapter  1 
are  analyzed  and  conclusions  reached  regarding  how  well  the  objectives  of  Chapter  1  have 
been  satisfied.  Finally,  recommendations  for  further  research  are  presented  which  may  help 
answer  some  of  the  questions  raised  by  this  thesis. 

5.2  Summary  of  Research 

This  thesis  directly  converted  the  Magic  layout  design  system  to  take  advantage  of 
the  database  facilities  of  ObjectStore.  A  design  recovery  of  Magic  revealed  the  database 
manager  module  to  be  the  critical  component  of  this  conversion.  The  data  structure  used 
by  the  database  manager  consists  of  a  cell  definition  for  each  VLSI  circuit  and  a  list  of  cell 
uses  for  each  particular  instance  of  the  cell  definition. 

Conversion  of  Magic  required  the  cell  definition  and  cell  use  data  structures  to  be 
persistently  allocated  using  the  persistent  new  command  of  ObjectStore.  File  input  and 
output  was  eliminated  since  the  data  structures  are  no  longer  destroyed  when  Magic  is 
shutdown.  Some  Magic  commands  were  modified  slightly  to  account  for  invalid  data  re¬ 
maining  in  the  database  along  with  data  which  the  designer  intends  to  keep. 

To  compare  the  performance  of  the  original  Magic  to  the  version  modified  to  work 
with  ObjectStore,  timing  routines  were  instrumented  in  the  code  to  measure  the  time 
required  to  complete  a  Magic  command.  Routines  were  also  added  to  measure  disk  a-ccss. 
Performance  testing  was  accomplished  using  Magic  commands  whicli  require  e.Ktensivc 
database  access.  Emphasis  in  performance  testing  was  placed  on  those  database  attributes 
specified  in  the  IlyperModel  Benchmark. 

5.3  Conclmions 

The  objectives  of  this  thesis  require  that  the  ObjectStore  version  of  Magic  provide 
the  full  functionality  of  the  original  version.  Response  time  must  not  increase  by  more 
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than  ten  percent  over  the  original  version.  This  thesis  also  attempts  to  demonstrate  that 
conversion  of  Magic  from  its  flat  file  data  management  system  to  ObjectStore  is  a  cost 
effective  undertaking.  The  results  of  Chapter  4  are  analyzed  in  the  folio',  g  subsections 
to  determine  whether  these  thesis  objectives  were  met. 

5.3.1  Database  Functionality.  As  described  in  its  documentation,  ObjectStore  pro¬ 
vides  support  for  complete  functionality  of  Magic  in  a  manner  similar  to  the  original  ver¬ 
sion.  While  some  commands  may  perform  in  a  slightly  different  manner,  the  same  functions 
are  supported.  Unfortunately,  however,  ObjectStore  does  not  work  entirely  as  described 
in  its  documentation.  The  primary  difference  is  implementation  of  ObjedStore’s  version¬ 
ing  facilities.  These  are  necessary  to  allow  Magic  to  roll  back  to  a  previously  baselined 
design.  The  versioning  facilities  do  not  work  correcily  with  ObjectStore  version  1.1,  so  the 
implementation  of  Magic  for  this  thesis  does  not  support  design  roU  back. 

5.3.2  Database  Performance.  The  results  presented  in  Chapter  4  show  Magic  to 
meet  performance  goals  for  only  three  of  the  six  areas  of  performance  benchmarK  testing: 
hierarchy  traversal  and  object  and  instance  insertion.  Because  of  this,  one  may  tend  to 
conclude  that  ObjectStore’s  performance  is  inadequate  for  supporting  complex  engineering 
design  systems  such  as  Magic.  R.G.G.  Cattel  suggests,  however,  that  benchmark  perfor¬ 
mance  tests  may  not  be  an  accurate  measure  of  performance;  rather  “The  most  accurate 
measure  of  performance  for  engineering  applications  would  be  to  run  an  actual  application 
....  (2:364)” 

When  actually  using  Magic,  the  difference  in  performance  was  not  readily  apparent. 
For  look  up  and  retrieval,  the  difference  in  response  time,  while  representing  an  increase  of 
nearly  200  percent,  was  still  only  measured  in  fractions  of  a  second  —  barely  perceptible  to 
a  human  user.  Database  initialization,  while  taking  42  percent  more  time  with  ObjectStore, 
is  only  performed  once  per  user  session.  Five  seconds  in  a  session  that  may  be  hours  long 
does  not  seriously  detract  from  overall  performance.  Closure  operations,  as  tested  with  the 
dre  catchup  command,  took  .-ucsiderably  longer  with  ObjectStore.  Even  with  the  original 
version  of  Magic,  however,  this  command  took  a  long  time  to  accomplish.  It  is  for  this 
reason  that  the  designers  of  Magic  expect  users  to  generally  run  the  design  rule  checker 
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in  the  background.  This  background  checking  can  be  turned  off  when  a  large  number  of 
changes  are  made  co  a  circuit  design.  When  the  changes  are  completed,  drc  catchup  will 
run  the  design  rule  checker  on  all  changes  made  during  the  session.  Again,  this  represents 
a  few  minutes  of  trade-off  in  performance  during  what  typically  is  an  hours  long  session. 

ObjectStore  required  a  considerable  amount  of  space  to  store  the  Magic  databases. 
In  the  original  environment  which  the  performance  tests  were  accomplished,  this  amount 
of  space  had  a  significant  impact.  With  the  current  implementation  of  Magic  using  a  single 
transaction,  no  segment  of  the  database  could  be  found  to  remove  from  memory  once  the 
entire  circuit  was  swapped  into  memory.  The  single  transaction  implementation  coupled 
with  the  large  database  size  led  to  memory  quickly  being  used  up  and  the  Magic  sys¬ 
tem  failing.  These  problems  do  not  necessary  reflect  poorly  on  object-oriented  databases, 
however,  since  proper  transaction  implementation  would  easily  overcome  the  problems. 
In  addition,  newer  releases  of  ObjectStore  are  projected  to  better  handle  such  i  lemory 
swapping  problems  (16). 

When  considering  the  performance  of  the  ObjectStore  version  of  Magic,  one  must 
realize  that  Magic  was  not  designed  using  object-oriented  programming  techniques.  Any 
optimization  built  into  the  Magic  code  is  designed  to  improve  efficiency  of  the  Unix  flat 
file  storage  system,  not  a  database  management  system.  The  fact  that  the  original  Magic 
design  does  not  take  advantage  of  these  fundamental  concepts  of  the  ObjectStore  database 
management  system  may  account  for  the  failure  ..»f  Magic  to  perform  as  well  with  Object- 
Store  as  it  does  with  its  current  Unix  flat  file  management  system.  That  the  ObjectStore 
version  of  Magic  performs  best  for  hierarchy  traversal  demonstrates  what  Object  Design 
considers  to  be  the  primary  benefit  of  ObjectStore’s  architecture  (9:61). 

Overall,  the  performance  results  obtained  from  implementing  Magic  with  ObjectStore 
are  inconclusive.  Benchmark  tests  indicate  that  ObjectStore  performance  falls  within  the 
ten  percent  increase  criteria  for  only  three  of  six  areas.  Actual  usage  of  Magic,  however, 
showed  that  the  areas  not  meeting  the  performance  criteria  are  unlikely  to  noticeably 
impact  the  overall  performance  of  Magic.  Modification  of  Magic’s  design  to  better  take 
advantage  of  ObjectStore’s  database  features  would  likely  improve  performance.  Similarly, 
memory  limitations  of  the  existing  implementation  provided  for  a  very  unstable  environ- 
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ment;  however,  proper  implementation  of  transactions  along  with  projected  upgrades  to 
the  ObjectStore  database  system  would  likely  eliminate  this  problem. 

5.3.3  Conversion  Cost  Effectiveness.  One  of  the  primary  costs  of  any  software  sys¬ 
tem  is  that  necessary  for  software  maintenance.  These  costs  can  be  minimized  if  software 
changes  affect  only  small,  localized  segments  of  code  and  if  maintainers  can  easily  un¬ 
derstand  the  organization  and  functionality  of  existing  code.  Object-oriented  computing 
attempts  to  minimize  the  impact  of  changes  through  data  encapsulation,  in  which  the 
underlying  data  is  accessible  only  through  a  well-defined  interface  (19).  Increased  under¬ 
standing  is  attained  through  abstraction,  a  concept  in  which  the  programmer’s  model  of 
an  object  more  closely  approximates  the  user’s  conceptual  model  of  the  object  (4).  A  data¬ 
base  management  system  also  supports  data  encapsulation  and  abstraction  by  providing 
mechanisms  for  defining  storage  structures  and  manipulating  information  (8). 

ObjectStore  supports  both  object-oriented  computing  and  database  management. 
With  its  persistent  data  structures  and  procedures  for  managing  data,  all  input  and  output 
procedures  can  be  eliminated  from  the  program.  This  eliminates  the  complexity  involved 
with  transforming  data  fr>.  n  its  flat  file  representation  to  the  appropriate  data  structure 
in  memory.  Unfortunately,  the  implementation  of  Magic  for  this  thesis  does  not  take 
full  advantage  of  ObjectStore’s  object-oriented  computing  facilities.  Because  the  interface 
to  the  database  is  not  well-defined,  a  change  in  the  database  structure  may  affect  many 
segments  of  the  system.  By  not  converting  Magic’s  existing  C  code  to  C++  which  is  used 
by  ObjectStore,  additional  complexity  was  added  since  both  a  C  and  a  C++  interface 
must  be  specified  for  each  module. 

ObjectStore  provides  the  capability  to  greatly  enhance  the  maintainability  of  Magic. 
Unfortunately,  by  failure  to  take  full  advantage  of  ObjectStore’s  object-oriented  facilities, 
and  through  offsetting  the  maintenance  advantages  of  a  database  management  system  with 
an  extra  interface  for  C++,  the  overall  maintainability  of  Magic  remains  about  the  same. 
No  maintenance  cost  savings  are  realized  with  the  version  of  Magic  implemented  for  this 
thesis. 
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On  the  other  hand,  the  costs  associated  with  converting  to  ObjectStore  were  rela¬ 
tively  high.  In  four  months  of  intense  study  and  programming  with  ObjectStore,  it  was 
not  possible  to  learn  and  understand  every  aspect  of  ObjectStore  or  to  even  completely 
understand  any  single  cispect.  No  programming  at  all  was  accomplished  using  Object- 
Store’s  collection  and  relation  facilities.  Versioning  Wcis  not  completely  implemented  due 
to  faults  in  the  ObjectStore  system.  In  some  instances,  the  documentation  inadequately 
or  improperly  described  ObjectStore  functionality,  thus  requiring  technical  support  from 
the  designers  of  ObjectStore  to  resolve  programming  issues. 

Another  significant  cost  associated  with  conversion  to  ObjectStore  was  modifying 
C  programs  for  compatibility  with  C++.  This  task  could  have  been  avoided  by  using 
ObjectStore ’s  C  library  interface;  however,  this  would  increase  the  effort  required  to  take 
advantage  of  the  object-oriented  programming  facilities  of  C++  at  a  later  time. 

The  ObjectStore  implementation  of  Magic  for  this  thesis  was  not  cost  effective.  The 
costs  associated  with  learning  the  ObjectStore  system  and  making  C  programs  compatible 
with  C++  were  not  offset  by  any  significant  improvement  in  maintainability.  A  complete 
redesign  using  object-oriented  techniques  which  take  advantage  of  ObjectStore ’s  data  defi¬ 
nition  and  manipulation  language  (DML)  would  significantly  increase  the  understandabil- 
ity  of  the  Magic  code  and  likely  reduce  future  maintenance  costs.  Such  a  redesign  would 
also  likely  improve  Magic’s  performance.  The  costs  of  a  complete  redesign  would  be  high, 
however,  suggesting  that  ObjectStore  may  be  better  suited  for  developing  new  systems 
or  converting  systems  that  are  already  object-oriented  rather  than  converting  a  complex 
system  design  such  as  Magic’s. 

5Jf  Recommendations  for  Further  Research 

This  thesis  did  not  take  advantage  of  the  object-oriented  facilities  of  the  ObjectStore 
DML,  nor  did  it  take  full  advantage  of  all  the  features  of  ObjectStore.  While  one  of 
the  goals  of  this  thesis  was  to  ohow  a  reduction  in  future  maintenance  costs,  little  was 
done  toward  attaining  this  goal.  Object-oriented  programming  was  expected  to  reduce 
maintenance  costs;  however,  no  such  modifications  were  made  to  the  Magic  code.  If  the 
database  manager  module  of  Magic  were  truly  object-oriented,  the  changes  to  implement 
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Magic  with  ObjectStore  would  have  been  limited  to  this  module.  To  show  that  this  is 
the  case,  future  research  should  be  directed  toward  implementing  the  database  manager 
module  of  Magic  using  good  object-oriented  C++  features.  Creating  a  C++  class  for 
the  cell  definition  and  each  of  its  subordinate  objects  would  significantly  increase  the 
understandability  and  maintainability  of  Magic’s  database  manager. 

As  currently  implemented  with  a  single  ObjectStore  transaction,  the  ObjectStore 
version  of  Magic  has  even  more  severe  memory  limitations  than  the  original  version  of 
Magic.  The  drfmchip  circuit  design  is  the  largest  circuit  which  can  be  loaded  into  memory. 
If  transactions  were  limited  to  the  smallest  set  of  instructions  necessary  for  maintaining 
database  consistency,  memory  would  only  be  limited  by  the  amount  of  available  disk  space. 
Minimizing  piocessing  within  a  transaction  would  also  improve  the  ability  for  concurrent 
access  of  the  database  by  more  than  one  user.  Smaller  transactions  lock  each  database 
segment  for  less  time,  thereby  giving  other  users  quicker  access  to  the  same  segment. 

Two  major  features  of  ObjectStore  were  not  used  in  this  implementation  of  Magic: 
relationships  and  collections.  Both  have  the  potential  to  reduce  the  complexity  of  the 
Magic  code.  The  cell  definition  structure  includes  relations  to  hash  tables,  cell  labels,  tiles, 
planes,  and  cell  uses.  Use  of  ObjectStore’s  relationship  and  inverse  relationship  features 
along  with  ObjectStore  collections  would  potentially  eliminate  the  complex  list  structures 
currently  used  for  labels  and  cell  uses.  ObjectStore’s  facilities  for  traversing  lists  could  be 
used  instead,  thus  reducing  the  amount  and  complexity  of  Magic  code.  Magic’s  collection 
facilities  could  also  directly  replace  the  symbol  tables  used  for  cell  definitions  and  cell 
configurations. 

The  versioning  facility  of  ObjectStore  was  not  completely  implemented  due  to  dis¬ 
crepancies  with  the  ObjectStore  system.  When  these  discrepancies  are  fixed,  versioning 
implementation  should  be  completed  to  allow  full  functionality  of  the  Magic  system.  In 
addition,  versioning  provides  the  capability  for  cooperative  work  on  a  circuit  design  in 
which  two  designers  may  work  on  the  same  circuit  at  the  same  time.  If  this  is  to  be  done, 
however.  Magic  must  ensure  that  the  two  users  do  not  make  conflicting  changes  unless 
facilities  are  provided  for  managing  these  changes. 
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5.5  Summary 

Overall  performance  of  Magic  as  implemented  for  this  thesis  does  not  justify  con¬ 
version  of  existing  applications  to  use  object-oriented  databases.  Many  questions  are  left 
unanswered,  however,  due  to  the  difficulties  encountered  while  implementing  Magic  with 
ObjectStore.  To  answer  these  questions  and  take  better  advantage  of  ObjectStore’s  facili¬ 
ties,  a  number  of  proposals  for  additional  research  are  presented.  It  is  quite  possible  that 
complete  implementation  of  these  proposals  would  lead  to  a  Magic  system  with  signifi¬ 
cantly  improved  maintainability  and  performance.  Object-oriented  database  management 
systems,  while  not  fully  proved  in  this  thesis,  stiU  present  the  potential  for  greatly  simplify¬ 
ing  the  development  and  maintenance  of  complex,  data  intensive,  engineering  applications. 
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Appendix  A.  Raw  Performance  Test  Results 


Original  version  of  Magic  using  drfmchip 


Command 

CPU 

Time 

Elapsed 

Time 

Page  Faults 

Disk  Blocks 

with  I/O 

w/o  I/O 

In 

Out 

load  drfmchip 

4 

7 

2 

0 

BH 

1 

0 

1 

0 

0.06 

1 

1 

1 

1 

0.06 

0.170 

5 

2 

0 

0 

0.08 

0.120 

2 

2 

1 

0 

0.06 

0.068 

0 

10 

0 

0 

expand 

6.71 

10.18 

833 

115 

3 

6.37 

7.84 

■ii 

510 

20 

4 

6.76 

9.83 

121 

745 

123 

3 

6.80 

10.71 

132 

797 

139 

4 

6.67 

9.88 

850 

129 

3 

6.44 

7.49 

661 

19 

3 

load  test 

IQ  j 

0.012 

0 

16 

0 

0 

0.013 

0 

17 

0 

0 

0.012 

0 

16 

0 

0 

HRI 

0.012 

0 

18 

0 

0 

Hu! 

0.012 

0 

16 

0 

0 

0.01 

0.016 

0 

23 

0 

0 

write  test 

■sa 

0.147 

0 

muQ 

1 

7 

IS9 

0.123 

0 

0 

7 

111 

0.093 

0 

Hi 

0 

6 

0.131 

0 

12 

0 

7 

0.02 

0.091 

0 

12 

0 

6 

0.00 

0.080 

0 

12 

0 

6 

initialize 

5.74 

11.87 

111 

159 

23 

1 

5.58 

85 

202 

5 

2 

5.55 

87 

200 

9 

2 

5.58 

11.16 

95 

196 

16 

6.12 

11.74 

107 

219 

19 

■1 

5.45 

8.18 

7 

245 

8 

1 

Original  version  of  Magic  using  drfmchip 
getcell  test  nested  8  deep  in  subcell  mcelllO 


CPU 

Elapsed 

Page  Faults 

Disk  Blocks 

Command 

Time 

Time 

with  I/O 

w/o  I/O 

In 

Out 

writeall  force 

2.54 

4.81 

9 

618 

8 

103 

1.61 

3.28 

2 

88 

0 

90 

1.58 

3.12 

0 

88 

0 

99 

2.38 

3.93 

0 

88 

3 

94 

2.42 

3.96 

0 

88 

0 

95 

1.61 

3.26 

0 

89 

5 

90 

getcell  test 

0.03 

0.076 

3 

1 

0 

0 

0.02 

0.013 

0 

0 

0 

0 

0.01 

0.013 

0 

0 

0 

0 

0.02 

0.085 

2 

0 

0 

0 

0.01 

0.012 

0 

0 

0 

0 

0.01 

0.010 

0 

1 

0 

0 

drc  catchup 

96.24 

97.59 

26 

93 

0 

0 

94.72 

96.26 

34 

8 

0 

0 

94.73 

95.70 

13 

13 

0 

0 

96.44 

97.14 

2 

173 

0 

0 

94.88 

95.55 

0 

2 

0 

0 

95.97 

96.77 

1 

0 

0 

0 

53 


Original  version  of  Magic  using  drfmchip 
getcell  test  nested  4  deep  in  subcell  big_nandmux 


CPU 

Elapsed 

Page  Faults 

Disk  Blocks 

Command 

Time 

Time 

w/o  I/O 

In 

Out 

writeaU  force 

0.70 

1.47 

48 

0 

45 

0.72 

1.50 

^■1 

48 

0 

48 

0.68 

1.48 

0 

48 

0 

45 

0.68 

1.52 

0 

48 

0 

43 

0.66 

1.51 

0 

48 

0 

50 

0.69 

1.48 

0 

48 

0 

43 

getcell  test 

0.01 

■Esa 

0 

1 

0 

0 

0.00 

Rn 

0 

0 

0 

0 

0.00 

iB 

0 

0 

0 

0 

0.00 

0.0075 

0 

0 

0 

0 

0.00 

0.0090 

0 

0 

0 

0 

drc  catchup 

6.15 

6.26 

0 

0 

0 

0 

6.20 

6.23 

0 

0 

0 

0 

6.17 

6.20 

0 

0 

0 

0 

6.18 

6.22 

0 

0 

0 

0 

6.18 

6.32 

0 

0 

0 

0 

6.22 

6.27 

0 

0 

0 

0 

54 


ObjectStore  (Cache  Size  2048  sectors)  version  of  Magic  using  drfmchip 
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ObjectStore  version  of  Magic  using  drfmchip 
getcell  test  nested  8  deep  in  subcell  mcelllO 


Command 

CPU 

Time 

Elapsed 

Time 

Page  Faults 

Disk  Blocks 

with  I/O 

w/o  I/O 

In 

Out 

getcell  test 

0.44 

0.54 

2 

15 

0 

0.37 

0.44 

2 

0 

0 

0.49 

0.49 

0 

160 

0 

0 

0.43 

0.44 

0 

0 

0 

0 

0.38 

0.38 

0 

1 

0 

0 

0.37 

0.42 

0 

0 

1 

drc  catchup 

403.77 

434.24 

HQ 

0 

0 

366.54 

369.31 

0 

0 

370.38 

373.34 

0 

728 

0 

0 

360.74 

363.55 

0 

14 

0 

0 

361.15 

368.24 

0 

2 

0 

0 

349.10 

351.85 

0 

1 

0 

0 
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ObjectStore  version  of  Magic  using  drfmchip 
getcell  test  nested  4  deep  in  subcell  bigjiandmux 


Command 

CPU 

Time 

Elapsed 

Time 

Page  Faults 

Disk  Blocks 

with  I/O 

w/o  I/O 

Out 

getcell  test 

0.03 

MM 

0 

4 

0 

0 

0.02 

mm 

0 

0 

0 

0 

0.02 

0 

0 

0 

0 

0.02 

0 

0 

0 

0 

0.02 

0.015 

0 

0 

0 

0 

0.02 

0.015 

0 

0 

0 

0 

drc  catchup 

18.43 

19.58 

11 

307 

0 

0 

17.73 

17.84 

0 

0 

0 

0 

18.34 

18.45 

0 

2 

0 

0 

17.83 

17.93 

0 

0 

0 

0 

18.53 

18.72 

0 

0 

0 

0 

18.55 

18.87 

0 

0 

0 

0 

ObjectStore  (Cache  Size  G40  sectors)  version  of  Magic  using  drfmchip 
getcell  test  nested  4  deep  in  subcell  bigjiandmux 


Command 

CPU 

Time 

Elapsed 

Time 

load  drfmcliip 

0.05 

0.31 

0.03 

0.38 

0.08 

0.32 

0.04 

0.29 

0.04 

0.21 

0.04 

0.48 

expand 

0.99 

4.55 

1.06 

1.06 

2.31 

5.39 

2.15 

5.79 

1.82 

4.87 

0.94 

4.59 

load  test 

0.045 

0.050 

iSI 

0.083 

III 

0.023 

HI 

0.021 

Us 

0.021 

initialize 

5.81 

13.83 

6.00 

10.53 

6.01 

15.19 

5.87 

12.54 

5.72 

21.45 

5.74 

17.75 

getcell  test 

0.09 

0.400 

0.03 

0.031 

0.03 

0.030 

drc  catchup 

23.97 

24.86 

23.72 

23.79 

23.34 

23.58 

23.20 

23.53 

23.41 

23.80 

23.34 

23.67 

Page  Faults 

Disk  Blocks 

with  I/O 

w/o  I/O 

In 

Out 

0 

40 

0 

0 

0 

51 

0 

0 

0 

31 

0 

0 

0 

29 

0 

0 

0 

33 

0 

0 

0 

33 

0 

0 

1 

358 

0 

0 

0 

0 

0 

0 

0 

529 

0 

0 

0 

528 

0 

0 

2 

521 

0 

0 

0 

345 

0 

0 

1 

23 

0 

0 

0 

23 

0 

0 

0 

25 

0 

0 

0 

23 

0 

0 

0 

22 

0 

0 

0 

22 

0 

0 

5 

527 

4 

1 

6 

493 

6 

1 

81 

434 

11 

2 

26 

520 

10 

2 

3 

491 

4 

47 

494 

13 

4 

31 

0 

0 

0 

0 

0 

0 

0 

0 

0 

13 

118 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

2 

0 

0 

0 

1 

0 

0 

0 

0 

0 

0 
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Original  version  of  Magic  using  tut4a 


Elapsed 

Page  Faults 

Disk  Blocks 

Command 

Time 

with  I/O 

w/o  I/O 

m 

Out 

load  tut4a 

|Kgg| 

4 

0 

1 

0 

RQI 

0 

7 

0 

0 

BBS 

0 

7 

0 

0 

WBm 

0 

8 

0 

0 

■tflW 

0 

7 

0 

0 

0.01 

0.013 

0 

7 

0 

0 

expand 

0.05 

■sa 

5 

2 

0 

0.04 

■19 

0 

0 

0 

0.03 

Ha 

0 

0 

0 

0.04 

H9 

0 

0 

0 

0.06 

msm 

0 

0 

0 

0.03 

0.066 

0 

4 

0 

0 

load  test 

0.01 

0.0088 

6 

0 

0 

0.01 

0.0085 

6 

0 

0 

0.01 

0.0077 

0 

7 

0 

0 

0.00 

0.0074 

0 

7 

0 

0 

0.00 

0.0076 

0 

7 

0 

0 

0.01 

0 

7 

0 

0 

write  test 

■iRiIJ 

0 

17 

7 

0 

12 

0 

1 

0 

12 

0 

0.02 

0.137 

0 

12 

Kl 

0.01 

0.128 

0 

12 

0 

0.02 

0.127 

0 

12 

initialize 

5.47 

9.34 

76 

■■Kg 

4 

1 

5.47 

8.10 

4 

m 

2 

o.  /S 

8.14 

0 

0 

2 

5.94 

8.52 

0 

319 

■a 

0 

5.80 

8.27 

4 

314 

4 

HI 

5.50 

8.85 

0 

319 

0 

■H 
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Original  version  of  Magic  using  tut4a 


Command 

CPU  1  Elapsed 
Time  |  Time 

Page  Faults 

Disk  Blocks 

with  I/O 

w/o  I/O 

In 

Out 

writeall  force 

1 

26 

0 

23 

■n 

0 

24 

0 

21 

■ifiM 

0.479 

0 

24 

0 

21 

0.04 

0.533 

0 

24 

0 

23 

0.10 

0.507 

0 

24 

0 

21 

0.04 

0.554 

0 

24 

0 

2.1 

getcell  test 

0.00 

1 

0 

0 

0 

0.00 

0 

0 

0 

0 

0.01 

IH 

0 

0 

0 

0 

0.00 

BBI 

0 

0 

0 

0 

0.00 

0 

0 

0 

0 

0.00 

■n 

0 

0 

0 

0 

drc  catchup 

0.52 

0.55 

0 

0 

0 

0 

0.55 

0.56 

0 

0 

0 

0 

0.47 

0.48 

0 

0 

0 

0 

0.55 

0.55 

0 

0 

0 

0 

0.48 

0.48 

0 

0 

0 

0 

0.55 

0.56 

0 

0 

0 

0 

60 
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